On Tue, 2013-12-03 at 14:41 -0500, Stephen Frost wrote:
> * Jeff Davis (pg...@j-davis.com) wrote:
> The extra catalog tables which store SQL scripts in text columns is one
> of my main objections to the as-proposed Extension Templates.
OK, that's what I thought. This seems like the root of your objection,
so let's focus here.
> The other big issue is that
> there isn't an easy way to see how we could open up the ability to
> create extensions to non-superusers with this approach.
Is this because of the namespace issue, or is there another problem
> What I think we should really be mulling over is if we need anything
> further when it comes to non-superuser extensions; a new namespace (eg:
> schemas for extensions, or maybe prefix for user extensions, or just a
> notion of ownership which gets combined with the name when doing
> operations with an extension)? a new name (not extensions, but
> something else)?
Agreed. Adding namespaces would best be done sooner rather than later.
> That's what I was thinking and hoping. :) Of course, we haven't yet
> figured out exactly what we want this special mode to look like, so it's
> a bit tricky to ask anyone to write such a tool. I keep thinking this
> should be something like: create a schema, set the search path to that
> schema, run the extension script more-or-less as is, then 'register'
> that schema as being an extension with a certain version. That
> 'registration' process could also handle renaming the schema, if the
> user wants the extension in a different schema (or perhaps the initial
> schema was some kind of "temporary" schema) or moving the objects into
> an existing schema, if that's what is requested.
An interesting idea to rely on schemas like that, but it seems a little
hackish. I'd prefer something that would be sane for a user to do
without the assistance of a tool. We can still recommend that they use
the PGXN format and the tool, of course.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: