On Mon, Dec 2, 2013 at 2:33 PM, Greg Stark <stark@mit.edu> wrote:
> On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> OK, I'll bite. I've been trying to stay out of this thread, but I
>> really *don't* understand what this patch is about. Extensions, as
>> they exist today, are installed from the filesystem and their contents
>> are not dumped. You're trying to create a new kind of extension which
>> is installed from the system catalogs (instead of the file system) and
>> is dumped. Why should anyone want that?
>>
>> It seems that part of the answer is that people would like to be able
>> to install extensions via libpq. You could almost write a client-side
>> tool for that today just by using adminpack to write the files to the
>> server, but you'd trip over the fact that files written by adminpack
>> must be in either the data directory or the log directory. But we
>> could fix that easily enough.
>
> Just tossing an idea out there. What if you could install an extension
> by specifying not a local file name but a URL. Obviously there's a
> security issue but for example we could allow only https URLs with
> verified domain names that are in a list of approved domain names
> specified by a GUC.
That's a different feature, but I don't see anything preventing
someone from implementing that as an extension, today, without any
core support at all. It would only be usable in cases where the share
directory is writable by the database server (i.e. low-security
installations) and you'd have to make it a function call rather than
piggybacking on CREATE EXTENSION, but neither of those things sound
bad to me. (And if they are bad, they could be addressed by providing
hooks or event triggers, leaving the rest of the functionality in the
extension module.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company