Re: [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as

"Magnus Hagander" <magnus@hagander.net> writes:

> The whole contrib thing confuses a lot of users. Is it included, or
> isn't it?  IMHO, that distinction need to be clear, and I thought we
> were working (if not actively then at least passively) to "retire"
> contrib, moving things either to core or to pgFoundry. Adding yet
> another important feature that's "just in contrib" is making things
> worse, not better.
> IMHO, of course ;-)

I disagree with this principle. I think contrib has a role to play and there
are modules which belong in contrib for now and forever. The key distinction
isn't code quality -- I think that's an effect rather than a cause. 

The key distinction is the intended audience. Contrib is for things which are
integral parts of the system and as such would be harder to maintain in
pgfoundry, but have a very limited audience, especially things that a typical
admin wouldn't necessarily want in his install for security or safety reasons.

So pageinspect, adminpack, pg_buffercache, pg_standby, etc, these are all
things which are tightly tied to the system. They often need to be modified
when making unrelated changes to the core and can't be maintained as a
separate add-on by a different group of maintainers. But they're not
appropriate to install by default because they have a limited audience.

Some of the modules in there are legacy modules which today would probably be
done as pgfoundry modules. The GIST data types, earthdistance, isn, etc. We
did actively prune out a lot of modules like that which were poorly maintained
and bitrotting. The ones which remain are in reasonably good shape and have
wide enough user-bases that moving them to pgfoundry would cause more upgrade
pain than it would help.

But that doesn't mean we're phasing contrib out entirely. The question remains
whether txid is more like pageinspect/pg_standby/etc or more like
earthdistance/isn. It does sound like the whole point of it is to provide an
interface to core that pgfoundry modules can use, so presumably it's dealing
with the nitty gritty stuff that pgfoundry modules would have trouble
maintaining. Also, we only want *one* official such module. I think pushing it
to pgfoundry doesn't make any sense.

Does it make sense to put it in core? it has a limited audience in that only
skype and slony users need it. On the other hand there's not much reason an
admin wouldn't want it installed I don't think.

What happens if we put it in core now and then the replication folk add more
to the interface and include things that not all admins would want installed?
And is the interface mature enough that users should be building applications
depending on this interface directly?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com