* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > What is the next step to allow an extension pulled down from pgxn to be
> > installed, unchanged, into a given database?
>
> An extension packaging system.
>
> Unchanged is not a goal, and not possible even today.
I'm not convinced of that, actually, but you do raise a good point.
> PGXN is a *source based* packaging system. You can't just install what's
> in PGXN on the server's file system then CREATE EXTENSION, you have this
> extra step called the “build”.
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.
> 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.
> Which is what I think the pex extension is doing, and that's not
> coincidental, but it runs the build step on the PostgreSQL server itself
> and needs to have a non-trivial set of file-system privileges to be
> doing so, and even needs to get root privileges with sudo for some of
> its operations.
pex is an interesting beginning to this, but we'd need *some* backend
support for being able to install the extension via libpq (or pex would
need to be modified to not actually use our extension framework at
all for 'trusted' extensions...).
Thanks,
Stephen
