Re: Extension Templates S03E11 - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Extension Templates S03E11
Date
Msg-id m261r7m37a.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Extension Templates S03E11  (Greg Stark <stark@mit.edu>)
Responses Re: Extension Templates S03E11
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> OK, I'll bite.  I've been trying to stay out of this thread, but I
>> really *don't* understand what this patch is about.  Extensions, as

Thanks!

>> they exist today, are installed from the filesystem and their contents
>> are not dumped.  You're trying to create a new kind of extension which
>> is installed from the system catalogs (instead of the file system) and
>> is dumped.  Why should anyone want that?

To benefit from ALTER EXTENSION … UPDATE … and \dx.

And technically the extension is not dumped, its templates are.

>> It seems that part of the answer is that people would like to be able
>> to install extensions via libpq.  You could almost write a client-side
>> tool for that today just by using adminpack to write the files to the
>> server, but you'd trip over the fact that files written by adminpack
>> must be in either the data directory or the log directory.  But we
>> could fix that easily enough.

Trick question: when you've implemented said client and used it for a
couple of (in-house) extensions, what do you think should happen at
pg_restore time?

Hint: in a properly designed ops model, pg_restore happens each and     every day when the unattended cron job
“rebases”the QA or testing     environments from the production PITR backups, of course. 

> Just tossing an idea out there. What if you could install an extension
> by specifying not a local file name but a URL. Obviously there's a
> security issue but for example we could allow only https URLs with
> verified domain names that are in a list of approved domain names
> specified by a GUC.

That's something I want to build. This time, not in core.

The model I've been thinking about involves an EVENT TRIGGER that is
fired at "ddl_command_start" for CREATE EXTENSION and prepares an
EXTENSION TEMPLATE before the command has a chance to check what's
available and install the current default version of it.

Also runs at ALTER EXTENSION … UPDATE …, of course, providing the
upgrade scripts on the fly.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Trust intermediate CA for client certificates
Next
From: Tom Lane
Date:
Subject: Re: Trust intermediate CA for client certificates