* Jeff Davis (pgsql@j-davis.com) wrote:
> On Tue, 2013-12-03 at 09:20 -0500, Stephen Frost wrote:
> > * Jeff Davis (pgsql@j-davis.com) wrote:
> > > Stephen mentioned using external tools and/or metadata, but to me that
> > > sounds like it would require porting the extension away from what's on
> > > PGXN today.
> >
> > Not at all- and that'd be the point. An external tool could take the
> > PGXN extension, run 'make', then 'make install' (into a userland
> > directory), extract out the script and then, with a little help from PG,
> > run that script in "extension creation mode" via libpq.
>
> What is stopping Extension Templates, as proposed, from being this
> special "extension creation mode"? What would be a better design?
The extra catalog tables which store SQL scripts in text columns is one
of my main objections to the as-proposed Extension Templates. I view
those scripts as a poor man's definition of database objects which are
defined properly in the catalog already. 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.
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)?
> It seems like the porting issue is just a matter of finding someone to
> write a tool to reliably translate packages from PGXN into a form
> suitable to be sent using SQL commands; which we would need anyway for
> this special mode.
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.
Thanks,
Stephen