Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan <andrew@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
