Christopher Browne <cbbrowne@gmail.com> writes:
> I don't expect the extension system to help with any of this, since if
> "production folk" try to install minimal sets of packages, they're
> liable to consciously exclude extension support. The "improvement"
> would come from drawing contrib a bit closer to core, and encouraging
> packagers (dpkg, rpm, ports) to fold contrib into "base" rather than
> separating it. I'm sure that would get some pushback, though.
What I think the next step is here is to better classify contribs/ into
what we consider production ready core extension (adminpack, hstore,
ltree, pgstattuple, you name it — that's the trick), code example (spi,
some more I guess) and extensibility examples (for hooks or whatnot).
We've been talking about renaming contrib for a long time, but that will
not cut it. Classifying it and agreeing to maintain some parts of it
the same way we maintain the core is what's asked here. Is there a will
to go there?
If there's a will to maintain some contribs the way core is maintained
itself, we have to pick a new name for that, and to pick a list of
current contribs to move in there. Then packagers will either include
that in the main package or have the main package depend on the new one.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
