Magnus Hagander <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq