Magnus Hagander <magnus@hagander.net> writes:
> Right. My thought is still that if it isn't good enough for core, it
> shouldn't be in contrib. If it *is* good enough, and we want it, we
> should accept that it came in long after freeze and put it in core
> anyway. If it *isn't*, then it should be on pgfoundry and be moved into
> core when it's ready - for 8.4 or so.
The long and the short of it was that the patch wasn't ready. To put it
in core for 8.3, we'd have either had to delay the beta yet more, or
force initdb post-beta1, neither of which would have flown.
> The whole contrib thing confuses a lot of users.
To me, contrib exists mostly as a forcing function to ensure that we
keep the extension-module system working. If we got rid of it entirely,
as some here propose, we'd be more likely to break things that we'd not
find out about until much later (like when some pgfoundry project tried
to update their code, which almost certainly wouldn't be till the next
beta cycle).
Contrib also has a role to play as a repository of code examples that
people can crib from when developing new extension modules. I would
not want to claim that it's all "best practice" code --- a lot of it
definitely isn't --- but it stands a lot better chance of representing
current good practice if it's maintained with the core code than if it's
out on pgfoundry. On pgfoundry, it won't get included in the global-
search-and-replace patches that we do so many of, and it'll most likely
accumulate a lot of cruft from trying to be compatible with multiple
core releases.
So I have no interest in trying to "retire" contrib. I think there's
room for debate about exactly which modules to include, of course.
regards, tom lane
