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.
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.
Also remember that we're limiting this feature to SQL only extensions
(because we don't want to be loading our .so from anywhere in the system
and forcing them into a place owned by root is giving confidence, IIUC).
With SQL only extensions, it's all non-superuser land anyway.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support