* Jeff Davis (pg...@j-davis.com) wrote: > On Tue, 2013-12-03 at 09:20 -0500, Stephen Frost wrote: > > * Jeff Davis (pg...@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
signature.asc
Description: Digital signature