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.
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.
That's were I though about pushing the whole thing down to the catalogs
and have the backend take control from there.
>> What I want to build is an “extension distribution” software that knows
>> how to prepare anything from PGXN (and other places) so that it's fully
>> ready for being used in the database. Then the main client would run as
>> a CREATE EXTENSION "ddl_command_start" Event Trigger and would fetch the
>> prepared extension for you and make it available, then leaving the main
>> command operate as intended.
>
> I really don't think that's a good approach.
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
doesthe 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.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support