> > 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
