Re: Core Extensions relocation

Greg Smith <greg@2ndquadrant.com>

From: Greg Smith <greg@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2011-11-19T16:44:46Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Updates to contrib/isn ISBN tables.

  2. Add a "LIKE = typename" clause to CREATE TYPE for base types. This allows

On 11/18/2011 09:35 AM, Tom Lane wrote:
> Subdividing/rearranging contrib makes the packager's
> life more complicated, *and* makes his users' lives more complicated,
> if only because things aren't where they were before.  It seems unlikely
> to happen, at least in the near term.
>    

Users are visibly suffering by the current packaging.  Production DBAs 
are afraid to install contrib because it's described as untrustworthy.  
They are hit by emergencies that the inspection tools would help with, 
but cannot get contrib installed easily without root permissions.  They 
have performance issues that the contrib modules I'm trying to relocate 
into the server package would help with, but company policies related to 
post-deployment installation mean they cannot use them.  They have to 
always be installed to make this class of problem go away.

If you feel there are more users that would be negatively impacted by 
some directories moving than what I'm describing above, we are a very 
fundamental disagreement here.  The status quote for all of these 
extensions is widely understood to be unusable in common corporate 
environments.  Packagers should be trying to improve the PostgreSQL 
experience, and I'm trying to help with that.

In the face of pushback from packagers, I can roll my own packages that 
are designed without this problem; I'm being pushed into doing that 
instead of working on community PostgreSQL already.  But I'd really 
prefer to see this very common problem identified as so important it 
should get fixed everywhere instead.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us