"Joshua D. Drake" <jd@commandprompt.com> 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.
> 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've explained why I think this code belongs in Postgres and not pgfoundry,
did you have any counter-argument?
And the complaints Tom brought up are mostly precisely the kind of interface
issues that actually argue well for it being in contrib. 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.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com