Robert Haas <robertmh...@gmail.com> writes: > On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan <and...@dunslane.net> wrote: >> The biggest problem is that packagers tend just to bundle contrib together >> in one lump. If we could divide it into two, something like "standard >> modules" and "misc", with the former being included with the server package, >> I think that would be an advance, although packagers might reasonably want >> to treat pgcrypto as a special case.
As an ex-packager, I agree that would be a good thing. In particular we should try to avoid people packaging stuff that's meant either for server testing or as sample-source-code-not-useful-in-itself. We've made some progress on the former via src/test/modules but I wonder if we're all the way there; test_decoding surely shouldn't be in contrib on this measure should it? BTW, pg_upgrade is also a special case from a packager's viewpoint, since it needs to be bundled with back-version executables. > The problem is that it's very hard to agree on which stuff ought to be > standard and which stuff ought to be misc. There's probably some > stuff that almost everyone would agree is pretty useful (like hstore > and postgres_fdw) but figuring out which stuff isn't useful is a lot > harder. Almost anything you say - that's junk - someone else will say > - no, that thing is great, I use it all the time. For example, I just > offered contrib/isn as a sort of archetypal example of stuff that's > pretty marginal crap and Josh immediately came back and said, hey, I > use that! I don't see any principled way of getting past that > difficulty. Just because a module isn't regularly used by someone who > reads -hackers daily doesn't mean it's not worth keeping. Yeah. One possible way of measuring this would be to go through the commit logs and count commits in contrib/ that either added a new feature or fixed a field-reported bug (ie, did not arise simply from core-code-driven housekeeping). Either would be solid evidence that somebody out there is using it. Gathering the evidence would be pretty tedious though :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers