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

Re: UTF8MatchText

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: db(at)zigo(dot)dhs(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: UTF8MatchText
Date: 2007-05-21 16:59:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> But why are we doing that CHAREQ?
> To avoid the cost of the recursive call, just like it says.
>> If it succeeds we'll 
>> just do it again when we recurse, I think.
> If you move the other two cases then you could advance t and p before
> entering the recursion.

Yeah. Since I have removed the "_" case I believe it's now safe there to 
use BYTEEQ/NextByte, and since they are sufficiently cheap it's not 
worth worrying about.

Attached is a patch version that I think draws together all the threads 
of discussion so far. It's in fact quite a lot simpler than the existing 
code, with no special UTF8 case - this should improve LIKE/ILIKE 
processing for all charsets.

More eyeballs please for nasty corner cases.



Attachment: like.patch
Description: text/x-patch (25.5 KB)

In response to

pgsql-hackers by date

Next:From: Karl O. PincDate: 2007-05-21 17:02:29
Subject: Re: COPY into a view; help w. design & patch
Previous:From: Jim C. NasbyDate: 2007-05-21 16:23:57
Subject: Re: COPY into a view; help w. design & patch

pgsql-patches by date

Next:From: Peter EisentrautDate: 2007-05-21 17:11:50
Subject: Re: xpath_array with namespaces support
Previous:From: Jeff DavisDate: 2007-05-21 15:24:21
Subject: Re: Synchronized Scan

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