2015-05-29 8:20 GMT+02:00 Guillaume Lelarge <guilla...@lelarge.info>:
> Le 29 mai 2015 8:10 AM, "Pavel Stehule" <pavel.steh...@gmail.com> a > écrit : > > > > 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. > > > > I agree it's hard to compile an extension on Windows, but that's already > what we have. And I'm sure EDB will put all interesting contrib modules in > their windows installer to help users. They already go way further than any > Linux packages. > I afraid so dependency on EDB in this case is wrong - I have respect to EDB due work, but installation other extension from EDB stack is difficult, unclean, and nothing what I would to use as new base. > > 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 > > > > >
