I only did some cursory tests, but the patch (applied to Macport's beta2 di=
stribution) seems to be working on my dev box (OSX / Snow Leopard).
I'll report back if I run into oddities further down the road.
Thanks a lot!
Denis
>________________________________
>From: Jeff Davis <pgsql@j-davis.com>
>To: oleg@sai.msu.su
>Cc: Denis de Bernardy <ddebernardy@yahoo.com>; Teodor Sigaev <teodor@sigae=
v.ru>; pgsql-bugs@postgresql.org
>Sent: Sunday, June 19, 2011 7:23 PM
>Subject: Re: PG regression with row comparison when btree_gist is enabled =
(BUG)
>
>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:
>>=20
>>=A0 /*=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20
>>=A0 =A0 * If we can't find any opfamily containing the op, perhaps it is a
>> <>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20
>>=A0 =A0 * operator.=A0 See if it has a negator that is in an
>> opfamily.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0=20
>>=A0 =A0 */
>>=A0 op_negated =3D false;
>>=A0 if (catlist->n_members =3D=3D 0)
>>=20
>>=20
>> However, that's a bogus test, because btree_gist puts <> into an
>> opfamily. Thus, catlist->n_members =3D=3D 1 even though we really do nee=
d to
>> look for the negator. Really, we need to unconditionally search for the
>> operator as well as unconditionally searching for the negator.
>
>Patch attached.
>
>Regards,
>=A0=A0=A0 Jeff Davis
>
>
>=
