Re: Extension Templates S03E11 - Mailing list pgsql-hackers

* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Fine- so we need a step that goes from 'source' to 'built'.  I don't see
> > that step being done in or by a PG backend process.  Adding a new option
> > which can take a pgxn source and build a script from it which can be run
> > against PG via libpq is what I'd be going for- but that script *just
> > installs (or perhaps upgrades) the extension.*  There's no need for that
> > script, or various upgrade/downgrade/whatever scripts, to be sucked
> > wholesale into the PG catalog.
>
> As you said previously, we can't ask extension authors to control what
> version of their extension is installed on which database, so we need a
> way to cooperate with the backend in order to know how to operate the
> update.

Sure, that sounds reasonable..

> We can't just pull data out of the backend to do that, not until we've
> been pushing the list of available versions and update scripts that we
> have to be able to run the update.

I'm not following this, nor why we need this master list of every
extension which exists in the world to be in every PG catalog in every
database out there.

> That's were I though about pushing the whole thing down to the catalogs
> and have the backend take control from there.

I can appreciate the desire to do that but this particular piece really
feels like it could be done better external to the backend.  To go back
to my OS example, I feel Debian is better off with apt-get/aptitude
being independent from dpkg itself.

> What's your alternative? Goals are:
>
>   - using the update abilities of the extension mechanism
>   - no access to the server's file system needed
>   - pg_restore does the right thing
>
> I went for the whole set of extension abilities in my patch, you're
> pushing hard for me to reduce that goal so I only included the ability
> to manage version upgrades here.

I'd like to see these goals met, I just don't see it being all done in C
in the PG backend.  I've tried to outline my thoughts about how we
should keep the actual extension creation scripts, upgrade scripts, etc,
out of the backend catalogs (and not on the filesystem either..) and let
those be managed externally, but that does then require that when we
actually dump the extension's objects instead of just
'CREATE EXTENSION blah;'.  I understand there have been objections
raised to that, but I wonder if that isn't mainly because we're calling
these new things "extensions" which have this built-in notion that
they're coming from an OS packaging system which installs files
somewhere..  We certainly have none of these qualms about dumping and
restoring all the objects in a given schema.
Thanks,
    Stephen