Re: Extension Templates S03E11 - Mailing list pgsql-hackers

On Mon, 2013-12-02 at 11:07 +0200, Heikki Linnakangas wrote:
> On 12/02/2013 05:34 AM, Stephen Frost wrote:
> >>    2. When 9.4 gets released, we need some solid advice for extension
> >> authors. If they have a native shared library, I assume we just tell
> >> them to keep using the file-based templates. But if they have a SQL-only
> >> extension, do we tell them to port to the in-catalog templates? What if
> >> they port to in-catalog templates, and then decide they just want to
> >> optimize one function by writing it in native code? Do they have to port
> >> back? What should the authors of SQL-only extensions distribute on PGXN?
> >> Should there be a migration period where they offer both kinds of
> >> templates until they drop support for 9.3?
> >
> > This is one of the main things that I think Heikki was trying to drive
> > at with his comment- we really don't *want* to make extension authors
> > have to do anything different than what they do today.  With an external
> > tool, they wouldn't need to and it would just be two different ways for
> > an extension to be installed into a given database.  In the end though,
> > if we're telling people to 'port' their extensions, then I think we've
> > already lost.
> 
> Exactly.
> 
> There should be no difference between file-based extensions and 
> catalog-based extensions. It's just two different ways to install the 
> same extension. The extension author doesn't need to care about that, 
> it's the DBA that decides which method to use to install it.
> 
> I'm going to object loudly to any proposal that doesn't meet that criteria.

But we're arguably already in this position today. For a SQL-only
extension, the author can choose between:

1. Using a schema/namespace a. installable over libpq b. installable by non-superusers c. no special handling when it
comesto administration
 

2. Using an extension a. convenient metadata (e.g. "requires") b. upgrade scripts c. omitted from pg_dump so can be
managedseparately d. relocatable e. not tied to one schema
 

And if the author decides to change, it requires porting the extension
to the other form.

Note: I'm using "extension" loosely here. We might call the SQL-only,
user-installable variety something else.

So how do we get to the point where we have clear advice to the author
of a SQL-only extension? And how do we do that without asking them to
port anything?

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.

Regards,Jeff Davis