On Tue, Sep 13, 2011 at 10:13 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@oss.ntt.co.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers