Le 23 janvier 2012 11:53, Dimitri Fontaine <dimitri@2ndquadrant.fr> a écrit :
> 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.
if we agree to have that per cluster, then it can be in the
$pgdata/pg_extension or something similar...
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
