From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extension Templates S03E11 |
Date: | 2013-12-02 20:02:17 |
Message-ID: | m261r7m37a.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-12-02 20:07:48 | Re: Trust intermediate CA for client certificates |
Previous Message | Andrew Dunstan | 2013-12-02 20:01:25 | Re: Trust intermediate CA for client certificates |