Re: Core Extensions relocation - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Core Extensions relocation
Date
Msg-id 4EC6260F.6080703@2ndQuadrant.com
Whole thread Raw
In response to Re: Core Extensions relocation  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Core Extensions relocation
List pgsql-hackers
On 11/17/2011 03:18 PM, Peter Eisentraut wrote:
> Who's to say that after this, the core extensions won't end up in a new
> separate package postgresql-extensions (or similar) or might even stay
> in postgresql-contrib, for compatibility?
>    

I don't know why packagers would make an active decision that will make 
their lives more difficult, with no benefit to them and a regression 
against project recommendations for their users.  The last thing anyone 
packaging PostgreSQL wants is more packages to deal with; there are 
already too many.  Each of the current sub-packages has a legitimate 
technical or distribution standard reason to exist--guidelines like 
"break out client and server components" or "minimize the package 
dependencies for the main server".  I can't think of any good reason 
that would inspire the sort of drift you're concerned about.

There's little compatibility argument beyond consistency with the 
previous packages.  The reason why this is suddenly feasible now is that 
the under the hood change are almost all hidden by CREATE EXTENSION.

And if some wanted to wander this way, they'll end up having to maintain 
a doc patch to address the fact that they've broken with project 
recommendations.  This text in what I submitted will no longer be true:

"This appendix contains information regarding core extensions that are 
built and included with a standard installation of PostgreSQL."

One of the reasons I picked the name I did was to contrast with the 
existing description of contrib:

"porting tools, analysis utilities, and plug-in features that are not 
part of the core PostgreSQL system, mainly because they address a 
limited audience or are too experimental to be part of the main source 
tree."

That says it's perfectly fine to make these optional in another 
package--they're not "part of the core".  That scary wording is 
practically telling packagers to separate them, so it's easy to keep the 
experimental stuff away from the production quality components.

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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Inlining comparators as a performance optimisation
Next
From: Pavel Stehule
Date:
Subject: proposal: better support for debugging of overloaded functions