Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
>> Interesting problem... the bug is in get_op_btree_interpretation() which
>> has code like this:
>> ...
>> However, that's a bogus test, because btree_gist puts <> into an
>> opfamily. Thus, catlist->n_members == 1 even though we really do need to
>> look for the negator. Really, we need to unconditionally search for the
>> operator as well as unconditionally searching for the negator.

> Patch attached.

I looked at this a bit. The proposed patch is inadequate, aside from
any excess lookups it introduces, because there is similar logic in
predtest.c. To make the world safe for btree_gist to do this, we'd have
to add extra lookup activity there as well.

Quite honestly, I think that the bug is that btree_gist took it upon
itself to invent <> as an indexable operator. The odds that that will
ever be of practical use seem negligible, and not at all adequate to
warrant adding extra cycles into mainstream code paths. It's not too
late to rip that out of 9.1, and that's what I think we should do.

regards, tom lane