On Mon, Dec 2, 2013 at 3:02 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> 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
>>> 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.
I don't see what benefit we get as far as ALTER EXTENSION .. UPDATE is
concerned. You've got to do some kind of DDL to load the update
script into the database, and then you've got to run the UPDATE
itself. That's pretty complicated. You could have done the same
thing by just ALTERing the extension, without actually needing the
update script uploaded into the database.
> And technically the extension is not dumped, its templates are.
But you *could* dump the extension, and in fact it would be simpler
than what you're actually doing.
>>> 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.
/me shrugs. You could just as well ask what happens when you've
installed postgresql but not postgresql-contrib and try to restore a
database that needs hstore. There's no getting around the fact that
if the extension isn't available, installation will fail. Nor is that
a bug. Still, I agree that there are use cases where that's not what
you want, and discussed some of them in the rest of the email from
which you took that quote.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
