RFC: Remove contrib entirely

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема RFC: Remove contrib entirely
Дата
Msg-id 55674016.80005@commandprompt.com
обсуждение исходный текст
Ответы Re: RFC: Remove contrib entirely  (Stephen Frost <sfrost@snowman.net>)
Re: RFC: Remove contrib entirely  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Hello,

This is a topic that has come up in various ways over the years. After 
the long thread on pg_audit, I thought it might be time to bring it up 
again.

Contrib according to the docs is:

"These include 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. This does not preclude their usefulness."

It has also been mentioned many times over the years that contrib is a 
holding tank for technology that would hopefully be pushed into core 
someday.

What I am suggesting:

1. Analyze the current contrib modules for inclusion into -core. A few 
of these are pretty obvious:
pg_stat_statementscitextpostgres_fdwhstorepg_crypto[...]

I am sure there will be plenty of fun to be had with what should or 
shouldn't be merged into core. I think if we argue about the guidelines 
of how to analyze what should be in core versus the merits of any 
particular module, life will be easier. Here are some for a start:
A. Must have been in contrib for at least two releasesB. Must have visible community (and thus use case)

2. Push the rest out into a .Org project called contrib. Let those who 
are interested in the technology work on them or use them. This project 
since it is outside of core proper can work just like other extension 
projects. Alternately, allow the maintainers push them wherever they 
like (Landscape, Github, Savannah, git.postgresql.org ...).

Why I am suggesting this:

1. Less code to maintain in core
2. Eliminates the mysticism of contrib
3. Removal of experimental code from core
4. Most of the distributions package contrib separately anyway
5. Some of core is extremely small use case (sepgsql, tsearch2, lo ...)
6. Finding utilities for PostgreSQL used to be harder. It is rather dumb 
simple teenage snapchat user easy now.
8. Isn't this what pgxs is for?
9. Everybody hates cleaning the closet until the end result.
10. Several of these modules would make PostgreSQL look good anyway 
(default case insensitive index searching with citext? It is a gimme)
11. Contrib has been getting smaller and smaller. Let's cut the cord.
12. Isn't this the whole point of extensions?

Sincerely,

jD

-- 
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Frost
Дата:
Сообщение: Re: rhel6 rpm file locations
Следующее
От: Robert Haas
Дата:
Сообщение: Re: fsync-pgdata-on-recovery tries to write to more files than previously