Re: bug of pg_trgm?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug of pg_trgm?
Date: 2012-08-10 23:19:45
Message-ID: 27741.1344640785@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Thu, Aug 9, 2012 at 3:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Probably a minimal fix for this could be made by backing up "endword"
>> one byte before returning it if in_escape is true when the second
>> loop exits. That would not scale up to preserving the state of
>> in_wildcard_meta, but since the second loop never advances past a
>> meta char, that's okay for the moment.

> Or what about extending get_wildcard_part() so that it accepts the pointer
> to in_escape as an argument? generate_wildcard_trgm() can know the last
> value of in_escape and specify it the next call of get_wildcard_part(). Looks
> very simple.

Yeah, I had considered pushing the state variables out to the caller.
If there were any prospect of wanting more state than just in_escape,
I'd be for that --- but I don't see any reason to possibly need more,
especially in view of your point that in_wildcard_meta isn't really
a single flag with an interpretation that remains fixed throughout.
I think it's probably better just to take care of the issue inside
get_wildcard_part, and not complicate its API.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-08-10 23:48:13 Re: -Wformat-zero-length
Previous Message Jeff Davis 2012-08-10 23:16:43 Re: 16-bit page checksums for 9.2