On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
> Quite honestly, I think that the bug is that btree_gist took it upon
> itself to invent <> as an indexable operator.
Well, it was following documentation that any extension could
potentially use. I think it's a stretch to call it a bug in anything
other than postgres.
So I think we'd need to introduce extra documentation to say that at
most one of an operator and its negator can be indexable; and we should
add a check to prevent that as well.
> 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.
Fair enough. I think it was kind of an interesting use case, and there
might be others like it; but I agree that it wasn't particularly
compelling.
The alternatives don't seem very attractive. To get it to work with one
lookup we'd have to either clutter the btree opclasses with "<>", or
invent a new syscache that has the AM as a key so we can filter out
non-btree opclasses.
I suppose this is another argument for type interfaces.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
