Re: Core Extensions relocation

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Core Extensions relocation
Дата
Msg-id 4EC6260F.6080703@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: Core Extensions relocation  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Core Extensions relocation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Inlining comparators as a performance optimisation
Следующее
От: Pavel Stehule
Дата:
Сообщение: proposal: better support for debugging of overloaded functions