Tom Lane wrote: > The patch you propose for this is really untenable: it will re-introduce > many corner cases that we got rid of years ago, for example cases > wherein pg_verifymbstr and pg_mbcliplen index off the end of the string > because they think the last character occupies more bytes than are > there.
> Another problem is that if the last character is several bytes long, > this coding would cause us to iterate through potentially many millions > of character values before giving up and truncating off the last > character. Hmm... OK, I see your points. I have another idea. 1. We prepare new operators ( <,<=,>,=>,= ) for text and bytea. 2. In make_greater_string(), if multi-byte-string was set and using locale-C and could not find greater string, returns bytea which has greater byte-code of last-character. User will get the following result. ======================================================================================================= -- 西 : 0xe8a5bf =# EXPLAIN ANALYZE SELECT * FROM test WHERE name LIKE '西%'; QUERY PLAN ---------------------------------------------------------------------------------------------------------------- Index Scan using test_name on test (cost=0.00..8.28 rows=1 width=4) (actual time=0.022..0.024 rows=1 loops=1) Index Cond: ((name >= '西'::text) AND (name < '\\xe8a5c0'::bytea)) Filter: (name ~~ '西%'::text) Total runtime: 0.053 ms (4 rows) ======================================================================================================= Is the idea reasonable ? Best regards, -- NTT OSS Center Tatsuhito Kasahara -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs