Re: Core Extensions relocation

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Core Extensions relocation
Date: 2011-11-18 09:31:59
Message-ID: 4EC6260F.6080703@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-11-18 11:24:58 proposal: better support for debugging of overloaded functions
Previous Message Simon Riggs 2011-11-18 08:53:09 Re: Inlining comparators as a performance optimisation