Le 23 janvier 2012 11:53, Dimitri Fontaine <dimi...@2ndquadrant.fr> a écrit : > Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers