|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Daniel Farina <daniel(at)heroku(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: Inline Extension|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... If people
> are doing management via "pure FEBE", good for them: but that doesn't
> explain why it shoudn't be done all in userspace, with all of the
> flexibility that gives.
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?
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".
regards, tom lane
|Next Message||Kohei KaiGai||2012-01-23 06:38:54||Re: PG-Strom - A GPU optimized asynchronous executor module|
|Previous Message||Christopher Browne||2012-01-23 05:29:27||Re: Vacuum rate limit in KBps|