On 2/14/17 2:05 PM, Tom Lane wrote:
Jim Nasby <jim.na...@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
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: