"Magnus Hagander" <magnus@hagander.net> writes:
> On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>> > I also agree with this. We have to pretend it isn't in /contrib now,
>> > figure out where want it, then put it there (contrib, pgfoundry, core).
>>
>> Putting it in core now would mean forcing a post-beta1 initdb, which
>> I don't think adequate cause has been shown for.
>
> Ok. In that case, my vote is pgfoundry (heh, I'm sure that's clear by now).
> I don't think an adequate cause to break all our procedures to stick it in
> core has been shown either.
I just don't see the point in putting it in pgfoundry. It's already in
pgfoundry as part of Skytools. The whole point of having such a datatype is to
build common interface to abstract away the internals of the database. That
makes the pgfoundry modules (Skytools and Slony) easier to maintain
separately. Putting txid on pgfoundry just means splitting one pgfoundry
package into two. Moving code around doesn't make it any easier to maintain,
the portion that depends on the database internals will still depend on
database internals.
Putting it in core or contrib means that when we change the snapshot mechanics
in 8.4 the same developer will be able to fix the module at the same time (and
find out if his changes break it at the same time). Also different versions of
Postgres would include appropriate txid modules without having to maintain a
single version with a million ifdefs to cover multiple versions of Postgres.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com