Christopher Browne <cbbro...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
