On Mon, Jan 23, 2012 at 8:25 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> "virtual directory" - e.g. CREATE TABLE pg_extension_virtualdir
>> (filename text, content text) which would be modifiable by the DBA and
>> would be searched either before or after the filesystem itself. This
>> catalog wouldn't be dumped by pg_dump, and there would be no changes
>> to how extensions whose files are loaded from this catalog are dumped
>> vs. those whose files are loaded from the filesystem. Rather, just as
>
> That's the thing I don't like in this approach. Maybe it's just me but
> the primary intention on working on extension was to make dump and
> restore do the right thing all by itself.
Well, fair enough: there's no accounting for taste. You could make my
solution work with pg_dump in a fully automated fashion if you dumped
out the "virtual directory" contents before dumping any CREATE
EXTENSION statements, but I'm not going to get up on my soapbox and
say that's the world's best design, so if you don't like it, fine!
I am pretty concerned that we find a design that does not involve
pg_dump needing to dump out the extension contents, though: that seems
to me to be missing the point of having extensions in the first place.
> Now if we have “inline” (SQL only) extensions, the right thing happens
> to be very different from when you're dealing with contrib like ones,
> namely I would want the script to be dumped.
>
>>> extension_inline_directory = '/path/to/some/writable/place'
>>
>> This is another possible approach, but it requires a bit more
>> configuration, and we'd better think carefully about what a malicious
>> non-superuser DBA can do by changing that GUC.
>
> I think Cédric nailed it down upthread, proposing that we just use a
> PGDATA sub directory called 'pg_extension'. In fact, that would need to
> be a per-database sub directory. Then there's nothing to setup, nothing
> to abuse.
Hmm, that might have something going for it. It seems comparatively
easy to implement, and it also seems to do a pretty good job hiding
the complexity under the hood where users don't have to worry about
it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company