Re: RFC: Remove contrib entirely - Mailing list pgsql-hackers

From Neil Tiffin
Subject Re: RFC: Remove contrib entirely
Date
Msg-id 95C83718-69F1-4DEA-B116-E77A4D1547F4@neiltiffin.com
Whole thread Raw
In response to Re: RFC: Remove contrib entirely  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: RFC: Remove contrib entirely  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
> On Jun 4, 2015, at 10:55 AM, Jim Nasby <Jim.Nasby@BlueTreble.com> wrote:
>
> Personally, I'd rather we publish a list of formally vetted and approved versions of PGXN modules. There are many
benefitsto that, and the downside of not having that stuff as part of make check would be overcome by the explicit
testingwe would need to have for approved modules. 

I have looked at PGXN and would never install anything from it.  Why?  Because it is impossible to tell, without inside
knowledgeor a lot of work, what is actively maintained and tested, and what is an abandoned proof-of-concept or idea.
Thereis no indication of what versions of pg any of PGXN modules are tested on, or even if there are tests that can be
runto prove the module works correctly with a particular version of pg.  There are many modules that have not been
updatedfor several years.  What is their status?  If they break is there still someone around to fix them or even cares
aboutthem?  If not, then why waste my time. 

So adding to Jim’s comment above, anything that vets or approves PGXN modules is, in my opinion, essentially required
tomake PGXN useful for anything other than a scratchpad.  A big help would be to pull in the date of the last git
commitin the module overview and ask the authors to edit the readme to add what major version of pg the author last
testedor ran on. 

When I install from contrib, at least I have some minimal assurance that the code is meant to work with the
correspondingversion of pg. 

Neil


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: RFC: Remove contrib entirely
Next
From: Peter Geoghegan
Date:
Subject: Re: Further issues with jsonb semantics, documentation