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 <j...@commandprompt.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >