Re: [COMMITTERS] pgsql: Added the Skytools extended trans action ID module to contrib as
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
(1) we've always been laxer about contrib than the core code,
While that appears to be true, I think
(a) there is no technical reason allowing us to do that, and
(b) most people don't seem to like it.
I will even go so far as to say there are technical reasons not to do it. I beleive that contrib is currently included in most if not all our packages. It certainly is on win32 and I think I've seen the RPMs. It may not be loaded by default but it's there. And that will have users expecting the same code quality as for the rest of the PGDG code. If we can't (or won't) do that, well,that's why we have pgfoundry.
/Magnus
Import Notes
Resolved by subject fallback