Re: Dumping an Extension's Script - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Dumping an Extension's Script
Date
Msg-id 8827.1354730142@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dumping an Extension's Script  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Dumping an Extension's Script  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2012-12-05 19:13:10 +0200, Heikki Linnakangas wrote:
>> And I still don't understand why pg_dump needs to know about any of this...

> Extensions should be fully per-database and we want pg_dump backups to
> be restorable into another database/clusters/servers.

Wait a minute.  I haven't bought into either of those statements, and
most particularly not the first one.

Upthread, Dimitri claimed that he wasn't creating two different kinds of
extensions with this patch, but the more I read about it the more it
seems that he *is* making a fundamentally different kind of animal.
And I don't think it's necessarily a good idea, especially not if we
still call it an extension.

I kind of like Heikki's idea of leaving CREATE EXTENSION alone and
inventing a separate "UPLOAD EXTENSION" operation, but there's a problem
with that: in many, probably most, installations, the server does not
and should not have permission to scribble on the directories where the
extension scripts are stored.  Possibly we could circumvent that by
creating an auxiliary extensions directory under $PGDATA.  (But then
it starts to seem like pg_dumpall --- not pg_dump --- ought to include
those files in its output...)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Dumping an Extension's Script
Next
From: Merlin Moncure
Date:
Subject: Re: json accessors