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 comes to administration
2. Using an extension
a. convenient metadata (e.g. "requires")
b. upgrade scripts
c. omitted from pg_dump so can be managed separately
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
