On Mon, Dec 2, 2013 at 7:46 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.)
Well none of this isn't implementable as an extension if you have
write access to the database server's share directory.
This is all about UI. CREATE EXTENSION is about having the core do the
bookkeeping about which files belong to which version of which
extension.
I thought the fundamental problem the "in-catalog" extensions were
trying to solve were the issue with not having access to the
filesystem. If that's the case then being able to say create extension
from http://... would solve that.
If the fundamental problem is that you want multi-tenant databases to
be able to have different .so files visible depending on which
database is opened then that's a bit trickier.
--
greg