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
