Re: Quick Extensions Question - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: Quick Extensions Question
Date
Msg-id 54F256AD-79C3-4B05-ADC8-5B74B6E7DB8D@kineticode.com
Whole thread Raw
In response to Re: Quick Extensions Question  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mar 3, 2011, at 11:09 AM, Tom Lane wrote:

> That's not a design, that's just a very arbitrary kluge.  And it doesn't
> solve anything at all that we need to solve today, because you can
> already assume that you're running on >= 9.1 just by the fact that
> you're writing an extension.  Having a solution for this in time for
> 9.2 will be plenty soon enough.

Fair enough.

> BTW, I don't see any good reason to distinguish "core" requires from
> non-core.  If anything, the spirit of an extension proposal should be
> trying to reduce the distinction between "core" stuff and "not-core"
> stuff, since part of the point of extensions is that features might
> migrate across that boundary.

Okay. My only concern on that front, with regards to a future design, is how things will be reserved. I suppose that
couldbe got 'round by preserving things starting with, say, "pg-" or "pg:" as core features. So if I released an
extensioncalled "xslt", it wouldn't conflict with the core xslt "extension". Or else core "extensions" would just have
theirnames implicitly reserved. 

FWIW, extension names are required to be unique on PGXN. So no two people can have an extension named "foo". I'd like
toget a list of core "extensions" reserved in the code soon so that no one tries to uploaded "plperl", for example.
Whatmight such a list look like? Just PLs plus ./configure options (pam, ldap, bonjour, etc.) plus "postgresql" itself,
ofcourse? 

Best,

David




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Quick Extensions Question
Next
From: Simon Riggs
Date:
Subject: Re: Sync Rep v19