On Tue, Feb 8, 2011 at 11:38 AM, Noah Misch <noah@leadboat.com> wrote:
> It's not as if this patch raised complex questions that folks need more time to
> digest. For a patch this small and simple, we minimally owe Pavel a direct
> answer about its rejection.
Well, I don't see how we can give a totally straightforward answer at
this point. There are several proposals on the table, and they have
different pros and cons. Nobody is completely happy with any of them,
AFAICT. I think as far as the original patch goes, it's rejected. Is
there a variant of that approach that gives the same benefit with
better style? I don't know. I might be able to figure something out
if I spent an afternoon on it, but why is that my job?
There is sometimes a perception among non-committers that committers
are hiding the ball, as if the criteria for patch acceptance were
purely arbitrary and we make people guess what we want and then
complain when we don't get it. I've even had that perception myself a
time or two, but I try hard not to do that and I think (hope) that
other committers do as well. I've had my own share of ideas that I
thought were good and then had to abandon them either because they had
some deficiency which someone pointed out to me and I had to give up,
or else because I couldn't get consensus that the new behavior was
better than the old, even though it emphatically seemed so to me.
I've also had plenty of ideas that got shot down multiple times before
finally being accepted. I can't, and don't, accept that there isn't
some way to improve the repeated detoasting situation, but I do not
know what the best solution is technically. I don't even have an
opinion, without a lot more work. And I certainly don't have the
ability to know what Tom or someone else will think about the code
that that solution requires. The only thing I think IS clear is that
despite three weeks of discussion, we have no consensus on any of the
proposed patches, nor is there any clear path to reaching a consensus.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company