From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: like/ilike improvements |
Date: | 2007-05-23 16:00:54 |
Message-ID: | 46546536.9070700@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>> We should only be able to get out of step from the "%_" case, I
>>> believe, so we should only need to do the first-byte test in that
>>> case (which is in a different code path from the normal "_" case.
>>> Does that seem right?
>>>
>>
>> At least put Assert(IsFirstByte()) in the main path.
>>
>> I'm a bit suspicious of the separate-path business anyway. Will it do
>> the right thing with say "%%%_" ?
>>
>>
>>
>
> Yes:
>
>
> /* %% is the same as % according to the SQL standard */
> /* Advance past all %'s */
> while ((plen > 0) && (*p == '%'))
> NextByte(p, plen);
I am also wondering if it might be sensible to make this choice once at
backend startup and store a function pointer, instead of doing it for
every string processed by like/ilike:
if (pg_database_encoding_max_length() == 1)
return SB_MatchText(s, slen, p, plen);
else if (GetDatabaseEncoding() == PG_UTF8)
return UTF8_MatchText(s, slen, p, plen);
else
return MB_MatchText(s, slen, p, plen);
I guess that might make matters harder if we ever got per-column encodings.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-23 16:07:10 | Re: like/ilike improvements |
Previous Message | Andrew Dunstan | 2007-05-23 14:52:44 | Re: like/ilike improvements |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-23 16:07:10 | Re: like/ilike improvements |
Previous Message | Andrew Dunstan | 2007-05-23 14:52:44 | Re: like/ilike improvements |