Tom Lane <tgl@sss.pgh.pa.us> writes:
> On reflection it seems like this patch is simply offering the wrong
> solution for the problem. I agree that it could be useful to install
> extensions without having direct access to the server's filesystem,
> but it doesn't seem to follow that we must lobotomize existing extension
> features in order to have that. I pointed out earlier that you could
> get such functionality via contrib/adminpack, though people not
> unreasonably complained that that was pretty ugly and low-level.
> But couldn't we define some SQL-level operations to allow installing
> extension control and script files?
Yeah, that's what I was trying to do…
> Probably the worst issue with that is that in typical installations,
> the share/extension/ directory would be read-only to the server, and a
> lot of people might be uncomfortable with making it writable. Not sure
> whether we should consider inventing another place to keep
> SQL-command-installed extensions, or just say "if you want this
> functionality you have to make share/extension/ writable".
So I've been wondering about storing the script content in the catalogs,
but you would have to store all the update scripts too and that's
useless because you want to dump the current state of the system, which
pg_dump is doing just fine.
Back to using the file system on the server when handed the script
content over the protocol, we could get there with a new GUC telling the
server where to find and store “inline” extensions, right?
extension_inline_directory = '/path/to/some/writable/place'
Then creating an extension would look in both the system extension
directory and the inline one, which covers dump and restore. Creating
an inline extension means creating the .control and the .sql files in
the extension_inline_directory, then running the current code.
I can adapt the patch to this behavior this week.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support