Re: RFC: Remove contrib entirely

2015-05-29 8:20 GMT+02:00 Guillaume Lelarge <guillaume(at)lelarge(dot)info>:

> Le 29 mai 2015 8:10 AM, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)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 <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
> >
> >
>