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

Re: like/ilike improvements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: andrew(at)supernews(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: like/ilike improvements
Date: 2007-05-22 19:04:32
Message-ID: 16336.1179860672@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
> On 2007-05-22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If "%" advances by bytes then this will find a spurious match.  The
>> only thing that prevents it is if "B" can't be both a leading and a
>> trailing byte of validly-encoded MB characters.

> Which is (by design) true in UTF8, but is not true of most other
> multibyte charsets.

> The %_ case is also trivially handled in UTF8 by simply ensuring that
> _ doesn't match a non-initial octet. This allows % to advance by bytes
> without danger of losing sync.

Yeah.  It seems we need three comparison functions after all:

1. Single-byte character set: needs NextByte and ByteEq only.

2. Generic multi-byte character set: both % and _ must advance by
characters to ensure we never try an out-of-alignment character
comparison.  But simple character comparison works bytewise given
that.  So primitives are NextChar, NextByte, ByteEq.

3. UTF8: % can advance bytewise.  _ must check it is on a first byte
(else return match failure) and if so do NextChar.  So primitives
are NextChar, NextByte, ByteEq, IsFirstByte.

In no case do we need CharEq.  I'd be inclined to drop ByteEq as a
macro and just use "==", too.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-05-22 22:37:24
Subject: Re: like/ilike improvements
Previous:From: markDate: 2007-05-22 18:44:25
Subject: Re: like/ilike improvements

pgsql-patches by date

Next:From: Andrew DunstanDate: 2007-05-22 22:37:24
Subject: Re: like/ilike improvements
Previous:From: markDate: 2007-05-22 18:44:25
Subject: Re: like/ilike improvements

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