From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: UTF8MatchText |
Date: | 2007-05-18 02:07:20 |
Message-ID: | 20070518105529.91CB.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> On the strength of this closer reading, I would say that the patch isn't
> relying on UTF8's first-byte-vs-not-first-byte property after all.
> All that it's relying on is that no MB character is a prefix of another
> one, which seems like a necessary property for any sane encoding; plus
> that characters are considered equal only if they're bytewise equal.
> So are we sure it doesn't work for non-UTF8 encodings? Maybe that
> earlier conclusion was based on a misunderstanding of what the patch
> really does.
Yes, I only used the 'disjoint representations for first-bytes and
not-first-bytes of MB characters' feature in UTF8. Other encodings
allows both [AB] and [BA] for MB character patterns. UTF8Match() does
not cope with those encodings; If we have '[AB][AB]' in a table and
search it with LIKE '%[BA]%', we judge that they are matched by mistake.
I've also misunderstood it before, and Dennis Bjorklund pointed out.
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01377.php
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-18 02:35:06 | Re: UTF8MatchText |
Previous Message | Tom Lane | 2007-05-18 01:30:53 | Re: interval / interval -> double operator |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-18 02:35:06 | Re: UTF8MatchText |
Previous Message | FAST PostgreSQL | 2007-05-18 01:47:01 | Re: Updateable cursors patch |