> > 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.
So if the patch wasn' ready, why did it get accepted for /contrib? > 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. So it should've been saved for 8.4. > > 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. Ok. But if that's what it's mainly for then we *really* shouldn't put things that we expect our users to rely heavily on. And if this thing will go deep into replication systems, that's exactly what it is. > 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. Same comment applies here. And it's certainly far from best practice if it "breaks the rules"... /Magnus ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend