I have so far implemented the following:
An operator class text_binary_ops that does memcmp()-based comparison of
text data. The operators are named $<$ etc. for lack of a better idea.
That lack is further illustrated by the idea to name them "binary-<" etc.,
which wouldn't get through the parser, but it doesn't need to.
The system will use such an index for the queries in question if the
locale is not "like-safe", in the terminology of the code (I'll end up
renaming that a little). If the locale is plain C/POSIX, it will use the
"normal" index. (Should it be able to use either one in that case?)
Open issues:
Currently, this only works on text. Before I go out and duplicate all
this code and the catalog entries for varchar and bpchar, is there a
Better Way?
In match_special_index_operator(), the code looks up the required
operators by name (<, >=). In other places we go out of our way to not
attach predefined meanings to operator names. (In yet other places we do,
of course.) Wouldn't it be better to test whether the candidate index is
a btree and then select the operator to use from the btree strategy
entries? One uglification factor here is that the comment
* We cheat a little by not checking for availability of "=" ... any * index type should support "=", methinks.
no longer holds.
PS: I wasn't able to find or reconstruct a concrete test case for this in
the archives. Naturally, I'd accept this approach on theoretical purity,
but if someone remembers a real tough one, let me know.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
