Skip site navigation (1) Skip section navigation (2)

Re: make_greater_string() does not return a string in some cases

From: Tatsuhito Kasahara <kasahara(dot)tatsuhito(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: make_greater_string() does not return a string in some cases
Date: 2010-06-23 09:42:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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
                                                   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

In response to


pgsql-bugs by date

Next:From: Josh BerkusDate: 2010-06-23 17:56:03
Subject: local_preload_libraries filenames converted to lowercase
Previous:From: Liang Giap WeeDate: 2010-06-23 08:14:58
Subject: Postgres on AIX5.3 and AIX6.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group