Re: RFC: Remove contrib entirely

Hi

I am not sure if PGXN can substitute contrib - mainly due deployment - It
doesn't helps with MS Windows. Installing necessary software for
compilation there is terrible.

Regards

Pavel

2015-05-28 18:19 GMT+02:00 Joshua D. Drake <jd(at)commandprompt(dot)com>:

>
> 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_statements
> citext
> postgres_fdw
> hstore
> pg_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 releases
> B. 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.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>