On Thu, Sep 22, 2011 at 2:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > The essential problem here is "when can you stop scanning, > given a pattern with this prefix?", and btree doesn't know any more > about that than make_greater_string does; it would in fact have to use > make_greater_string or something isomorphic to it.
Hm, as long as btree_pattern_ops is the only opclass that behaves this way that's more or less true. But Robert's right that if btree just stops when it finds something that doesn't match it doesn't need to hard code any knowledge of what the "next" value would be. If there were any other op classes that had this abstract property of always putting strings with common prefixes in a contiguous block then it would continue to work without having to know where to find the boundaries of that contiguous block. Just as an example, if you had a pattern_ops opclass that sorted the string assuming it was in some other encoding like, say, EBCDIC, then make_greater_string would have to learn about it but Robert's model would just work. This isn't enitirely facetious. Sorting by EBCDIC ordering would be silly but I vague recall there being some examples that wouldn't be silly. And perhaps some collations could actually be marked as being acceptable even if they don't sort in pure ascii ordering and make_greater_string doesn't actually know about them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
