Greg Stark <st...@mit.edu> writes: > On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers