On Sun, Aug 26, 2018 at 09:30:40PM -0400, Steve Singer wrote:
> On Fri, 24 Aug 2018, David Fetter wrote:
> >Folks,
> >
> >I'd like to get your take on $Subject. As the project lacked a time
> >machine, it was not possible to make the part installed inside the DB
> >an EXTENSION in the first place. For reasons of sanity, would be
> >convenient to make it one now.
> >
> >The part where it seems like there may be technical issues in the
> >implementation is the script-to-be, slony1--unpackaged--1.0.sql when
> >there are multiple replication sets, possibly with multiple versions
> >of the software.  Should that be supported, and if so, how?
> 
> How do you envision slony working as an extension?
> What would happen when someone calls 'create extension...'
> 
> Would this replace 'store node' or would the slonik code in 'store node...'
> call 'create extension...'

I'm thinking STORE NODE could check whether CREATE EXTENSION needed to
be called and then attempt to call it on its own.

There are a few things going on in Slony that don't draw boundaries
where the EXTENSION paradigm as I understand it does, but I don't
think they're fundamentally incompatible.

In Slony, both the software (that .so and some functions both in it
and in PL/pgsql) and the schema for a given installation get installed
at STORE NODE time.

In EXTENSIONs, the software would get installed via CREATE EXTENSION
at one point, and at some later point--possibly a few
milliseconds--the things specific to replication sets, subscriptions,
etc., would get set up, possibly by wrapper functions included in the
EXTENSION.

One benefit of arranging things this way would be to make it a lot
easier for the AWSs/GCPs/Azures/etc. of the world to make Slony
available as a .so they control.

Another, one I've stubbed my toe on a few times at various places, is
getting Slony to play nicer with tools like pg_dump/pg_restore by
attaching its dependencies through conventional paths through
pg_depend and friends. While it's certainly possible to create systems
and procedures that make this happen, getting a hand from pg_depend
and friends would make Slony a lot friendlier to larger audiences.

Back to an earlier question, do we support multiple versions of Slony
running on the same instance? If so, and we want to keep that
capability, we might need to do some hacks to ensure that the .so's
don't step on each other.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate