|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|To:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>|
|Subject:||Re: [v9.2] make_greater_string() does not return a string in some cases|
|Views:||Raw Message | Whole Thread | Download mbox|
On Tue, Sep 13, 2011 at 10:13 PM, Kyotaro HORIGUCHI
> This is rebased patch of `Allow encoding specific character
> Addition to the patch, increment sanity check program for new
> functions pg_generic_charinc and pg_utf8_increment is attached.
I took a look at this patch ... and the thread ... and the previous
thread with the same subject line:
As I understand it, the issue here is that when we try to generate
suitable > and < quals for a LIKE expression, we need to find a string
which is greater than the prefix we're searching for, and the existing
algorithm sometimes fails. But there seems to be some dispute over
how likely this is to occur. Tom argues that the case is so rare that
we shouldn't worry about it:
...while Kyotaro Horiguchi clearly feels otherwise, citing the
statistic that about 100 out of 7000 Japanese characters fail to work
That statistic seems to justify some action, but what? Ideas:
1. Adopt the patch as proposed, or something like it.
2. Instead of installing encoding-specific character incrementing
functions, we could try to come up with a more reliable generic
algorithm. Not sure exactly what, though.
3. Come up with some way to avoid needing to do this in the first place.
One random idea I have is - instead of generating > and < clauses,
could we define a "prefix match" operator - i.e. a ### b iff substr(a,
1, length(b)) = b? We'd need to do something about the selectivity,
but I don't see why that would be a problem.
The Enterprise PostgreSQL Company
|Next Message||Florian Pflug||2011-09-22 00:40:29||Re: Range Types - typo + NULL string constructor|
|Previous Message||Florian Pflug||2011-09-22 00:31:45||Re: Range Types - typo + NULL string constructor|
|Next Message||Josh Berkus||2011-09-22 00:37:15||Re: Broken selectivity with special inet operators|
|Previous Message||Tom Lane||2011-09-21 21:57:50||Re: Broken selectivity with special inet operators|