On 2/14/17 2:05 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> First, just to clarify: my reasons for proposing "core adoption" of PGXN
>> are not technical in nature.
>
> What do you think "core adoption" means? Surely not that anything
> associated with PGXN would be in the core distro.
No, certainly not. If anything, PGXN being a first class citizen would
allow for potentially removing code from core, since there would then be
a first-class way for users to add it.
>> Right now contrib is serving two completely separate purposes:
>
>> 1) location for code that (for technical reasons) should be tied to
>> specific PG versions
>> 2) indication of "official endorsement" of a module by the community
>
> This argument ignores what I think is the real technical reason for
> keeping contrib, which is to have a set of close-at-hand test cases
> for extension and hook mechanisms. Certainly, not every one of the
> existing contrib modules is especially useful for that purpose, but
> quite a few of them are.
I was under the impression that a lot of that had moved to test, but
yes, that's a consideration. That said, if local caching was added to
pgxnclient I don't think it'd require much change to just pull those
cases from PGXN instead of the core repo. Alternatively, they could be
pulled from a git repo that's houses the source code for the official
PGXN modules (or what PGXN calls a distribution).
Those kind of changes would actually help any extension author that
wants to depend on another extension (namely, automatically pulling
dependent extensions from PGXN). I have make targets that currently
accomplish this. They'd be nicer with some additions to both extensions
and PGXN, but IMHO they're workable right now.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
