Jeff Davis <pg...@j-davis.com> writes:
> I think that ripping out the change to btree_gist is also insufficient;
> we would also have to prevent other extensions from doing the same. That
> means documenting an odd special case, and testing for it when defining
> an opclass. And then we'd probably have to backpatch this kludge.
There is that. I doubt it's worth back-patching, though.
> Something simpler seems possible here. The root of the problem is that
> we're being fooled by GiST opclasses when all we care about are BTree
> opclasses anyway. A simple fix would be to introduce a flag
> "found_btree_op". If we hit any BTree entries from pg_amop at all, then
> we're done after the loop is done. If not, then we negate the op and
> loop again.
Yeah, I had been thinking along the same lines. It will require
duplicating the search loop, which is a bit annoying, but perhaps that
could be factored out as a subroutine.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
