From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuhito Kasahara <kasahara(dot)tatsuhito(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: make_greater_string() does not return a string in some cases |
Date: | 2010-06-23 22:23:39 |
Message-ID: | 29535.1277331819@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tatsuhito Kasahara <kasahara(dot)tatsuhito(at)oss(dot)ntt(dot)co(dot)jp> writes:
> 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.
> Is the idea reasonable ?
Maybe, but it only works for text_pattern_ops indexes not normal ones.
Not sure if people will be happy with maintaining a special index just
to cover this corner case.
I'm not convinced that there's enough of a problem here to be worth
sweating over. If we're not able to generate a "greater" string with
the current rules, the odds are that the pattern is so close to the end
of the index range that a one-sided test is not going to make much
difference compared to a two-sided one.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2010-06-24 01:02:43 | Re: Postgres on AIX5.3 and AIX6.1 |
Previous Message | Tom Lane | 2010-06-23 21:24:50 | Re: local_preload_libraries filenames converted to lowercase |