Tom Lane wrote:
> BTW, while I'm looking at this, I notice that there was an oversight in
> the change that made us throw an error for \ at the end of the LIKE
> pattern. We throw error in the first code chunk that deals with \
> but we don't do so here:
>
> if (plen
BTW, while I'm looking at this, I notice that there was an oversight in
the change that made us throw an error for \ at the end of the LIKE
pattern. We throw error in the first code chunk that deals with \
but we don't do so here:
if (plen < 2)
I wrote:
> No, that patch is just plain wrong. It eats %'s that would affect
> the later recursive MatchText calls.
Hmm ... actually, it's not wrong, but it's not good either. What we
really ought to do here is not just eat _'s following %, but eat *any
mixture of* % and _, advancing over a text
Bruce Momjian writes:
> Tom Lane wrote:
>> If tlen == 0 when we reach this loop, we'll fall through and fail.
>> But that is wrong since we need to consider the possibility that
>> the remaining pattern can match a zero-length substring. So the
>> loop needs to be changed to attempt a recursive M
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I have a feeling that this represents still another bug in the
> >> special-case path for % followed by _ (cf bug #4821). If so,
> >> maybe we ought to just toss out that optimization?
>
> > Yea, looks like it is this code in like_
Bruce Momjian writes:
> Tom Lane wrote:
>> I have a feeling that this represents still another bug in the
>> special-case path for % followed by _ (cf bug #4821). If so,
>> maybe we ought to just toss out that optimization?
> Yea, looks like it is this code in like_match.c:
No, actually it's th
Tom Lane wrote:
> "Markus" writes:
> > select 'ba' ilike '%__%';
> > return true as expected in 8.2 but false in 8.4.
>
> I have a feeling that this represents still another bug in the
> special-case path for % followed by _ (cf bug #4821). If so,
> maybe we ought to just toss out that optimizat
"Markus" writes:
> select 'ba' ilike '%__%';
> return true as expected in 8.2 but false in 8.4.
I have a feeling that this represents still another bug in the
special-case path for % followed by _ (cf bug #4821). If so,
maybe we ought to just toss out that optimization?
Markus wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5478
> Logged by: Markus
> Email address: markus.her...@outpost24.com
> PostgreSQL version: PostgreSQL 8.4.
> Operating system: Ubuntu 10.04
> Description:ILIKE operator returns wrong resul
The following bug has been logged online:
Bug reference: 5478
Logged by: Markus
Email address: markus.her...@outpost24.com
PostgreSQL version: PostgreSQL 8.4.
Operating system: Ubuntu 10.04
Description:ILIKE operator returns wrong result
Details:
The following query
10 matches
Mail list logo