Progress report on locale safe LIKE indexing
От | Peter Eisentraut |
---|---|
Тема | Progress report on locale safe LIKE indexing |
Дата | |
Msg-id | Pine.LNX.4.30.0108172005500.677-100000@peter.localdomain обсуждение исходный текст |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: