Tom Lane <tgl@sss.pgh.pa.us> writes:
> Sure, but that's a documentation issue, which again is not going to be
> helped by a source-tree rearrangement.
So we have several problem to solve here, and I agree that source code
rearrangement is fixing none of them. Maybe it would ease maintaining
down the road, though, but I'll leave that choice up to you.
Which contribs are ready (safe) for production? We could handle that in
the version numbers, having most of contrib at version 0.9.1 (say) and
some of them at version 1.0. We could also stop distributing examples
in binary form, only ship them in source package.
Then we need to include inspection extensions into the core packaging,
but still as extensions. That's more of a packager problem, except that
they need a clear and strong message about it. Maybe have a new
Makefile and build those extensions as part of the server build, and
install them as part as the "normal" install.
Another mix of those ideas is to ship inspection extensions and ready
for production ones all into a new package postgresql-server-extensions
that the main server would depend on, and the ones that are adding more
dependencies still in contrib, where not-ready for production extensions
would not get built.
This kind of ideas would also allow to quite easily remove things from
the main server and have them as extensions, available on any install
but a CREATE EXTENSION (WITH SCHEMA pg_catalog) command away. And still
maintained at the same quality level in the source tree.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support