Looking at the discussion, I think we should just keep it in /contrib.
The code is tightly tied to our backend transaction system so there is
logic to have it in /contrib rather than pgfoundry. I do think we
should just move it into core for 8.4 though.
Joshua D. Drake wrote:
-- Start of PGP signed section.
> On Wed, 10 Oct 2007 21:02:30 +0100
> Gregory Stark <[EMAIL PROTECTED]> wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > There are quite a few contributors that are upset that this whole
> > > process went down the way that it did. I would say they are likely
> > > in the majority versus the people that just want to leave it alone
> > > and move on.
> > > That means it is not complete. Which means we might as well look
> > > at Concurrent psql, Table function support, bitmap scan changes,
> > > and GIT as well.
> > That's just nonsense. We need to fix our other problems too and that
> > means getting substantive feedback to the authors of those patches so
> > they can complete the work. But that has no bearing whatsoever on the
> > current situation.
> You seem to be diverting my point. We can not provide preferential
> treatment. Those patches are out there and have been out there for some
> time. They followed the rules. Frankly, they deserve to be fully
> reviewed and have the opportunity to be put in core *before* this
> contrib patch.
> Especially since this patch has already been marked as *not complete*.
> There is already discussion happening on the patch and the changes that
> need to be made.
> > > Another option, is to push the contrib module to pgfoundry. There is
> > > zero loss here to PostgreSQL that I can see, in the current state
> > > of the patch.
> > You keep saying this, do you have any justification for it?
> I believe if you read my posts I have made plenty of justification. The
> simplest of course being, process wasn't followed.
> > I've explained why I think this code belongs in Postgres and not
> > pgfoundry, did you have any counter-argument?
> I believe I have mentioned that there is an argument for it to be in
> > And the complaints Tom brought up are mostly precisely the kind of
> > interface issues that actually argue well for it being in contrib.
> Nothing that is in contrib can not also be maintained just as well with
> pgFoundry. It just may take more proactiveness in the process.
> > It
> > serves its current purpose well but future users might need binary
> > i/o or subxid support and so on. Until the interface is very stable
> > being in contrib makes perfect sense.
> I would state that until the interface is very stable pgfoundry also
> makes perfect sense.
> I am getting the impression that you think that I don't *want* this
> module. I do, but I do not want it at the sacrifice of other modules
> and code authors who did the job the right way.
> I understand Tom's point about if we push to 8.4 that could cause
> problems for Slony and Skytools. I certainly don't want to cause
> problems for some very cool projects. I do however don't see those
> problems existing if it was in pgFoundry.
> Or are we saying that the only way to provide quality sofware to
> PostgreSQL is if it is either in core or contrib? I do not believe you
> are saying that.
> Joshua D. Drake
> === The PostgreSQL Company: Command Prompt, Inc. ===
> Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
> PostgreSQL solutions since 1997 http://www.commandprompt.com/
> UNIQUE NOT NULL
> Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
> PostgreSQL Replication: http://www.commandprompt.com/products/
-- End of PGP section, PGP failed!
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings