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

Re: [v9.2] make_greater_string() does not return a string in some cases

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [v9.2] make_greater_string() does not return a string in some cases
Date: 2011-09-22 00:35:02
Message-ID: CA+TgmoYO3UbyCekzDTdVWTG2goEQtr7H_f=9mous9u_uH_StSA@mail.gmail.com (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-bugspgsql-hackers
On Tue, Sep 13, 2011 at 10:13 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> This is rebased patch of `Allow encoding specific character
> incrementer'(https://commitfest.postgresql.org/action/patch_view?id=602).
>
> 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:

http://archives.postgresql.org/pgsql-bugs/2010-06/msg00303.php

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:

http://archives.postgresql.org/pgsql-bugs/2010-06/msg00336.php

...while Kyotaro Horiguchi clearly feels otherwise, citing the
statistic that about 100 out of 7000 Japanese characters fail to work
properly:

http://archives.postgresql.org/pgsql-bugs/2011-07/msg00064.php

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.

Thoughts?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Florian PflugDate: 2011-09-22 00:40:29
Subject: Re: Range Types - typo + NULL string constructor
Previous:From: Florian PflugDate: 2011-09-22 00:31:45
Subject: Re: Range Types - typo + NULL string constructor

pgsql-bugs by date

Next:From: Josh BerkusDate: 2011-09-22 00:37:15
Subject: Re: Broken selectivity with special inet operators
Previous:From: Tom LaneDate: 2011-09-21 21:57:50
Subject: Re: Broken selectivity with special inet operators

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