Re: bug of pg_trgm?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: bug of pg_trgm?
Дата
Msg-id 14123.1344446915@sss.pgh.pa.us
обсуждение исходный текст
Ответ на bug of pg_trgm?  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: bug of pg_trgm?
Re: bug of pg_trgm?
Список pgsql-hackers
Fujii Masao <masao.fujii@gmail.com> writes:
> When I used pg_trgm, I encountered the problem that the search result of
> SeqScan was the different from that of BitmapScan even if the search
> keyword was the same. Is this a bug?

Surely.

> The cause is ISTM that pg_trgm wrongly ignores the heading wildcard
> character (i.e., %) when an escape (i.e., \\) follows the wildcard character.
> Attached patch fixes this.

This patch doesn't seem quite right to me, though.  I agree that given
'%\x...', we should exit the loop with in_wildcard_meta still true.
However, if we have say '%\+...', the loop will continue, and now we
must reset in_wildcard_meta, no?  The next character is not adjacent to
a meta.  So I think in the "if (in_escape)" block, *both* assignments
should be moved after the iswordchr check.  Is there something I'm
missing?

Also, shouldn't we make a similar change in the second loop?  I guess
it's not strictly necessary given that that loop will exit as soon as
it sets in_wildcard_meta, but if you want to depend on that then the
reset in the second "if (in_escape)" block is altogether useless.  It
seems better to keep the logic of the two loops as similar as possible.

I'm also inclined to think that we should remove *both* flag resets
before the second loop.  The logic here is that we are reprocessing
the same character seen in the last iteration of the first loop,
right?  So the flag state ought to remain the same.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: WIP fix proposal for bug #6123
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Git diff patch in context diff format