On 09/06/2012 05:09 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/20/2012 01:26 PM, Tom Lane wrote:
Fujii Masao writes:
OK. Attached patch fixes the problem as you suggested, i.e., it backs up
"endword" if the second loop exits in an escape pair.
Applied with a bit of further adjustment
Andrew Dunstan writes:
> On 08/20/2012 01:26 PM, Tom Lane wrote:
>> Fujii Masao writes:
>>> OK. Attached patch fixes the problem as you suggested, i.e., it backs up
>>> "endword" if the second loop exits in an escape pair.
>> Applied with a bit of further adjustment of the comments. Thanks!
>
On 08/20/2012 01:26 PM, Tom Lane wrote:
Fujii Masao writes:
OK. Attached patch fixes the problem as you suggested, i.e., it backs up
"endword" if the second loop exits in an escape pair.
Applied with a bit of further adjustment of the comments. Thanks!
When movin
Fujii Masao writes:
> OK. Attached patch fixes the problem as you suggested, i.e., it backs up
> "endword" if the second loop exits in an escape pair.
Applied with a bit of further adjustment of the comments. Thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing
On Sat, Aug 11, 2012 at 8:15 AM, Tom Lane wrote:
> Fujii Masao writes:
>> No. ISTM that in_wildcard_meta must be reset before the second loop.
>> Because the meaning of that flag in the first loop is different from that in
>> the second loop. The former and the latter indicate whether the search
Fujii Masao writes:
> On Thu, Aug 9, 2012 at 3:05 AM, Tom Lane 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_met
Fujii Masao writes:
> On Thu, Aug 9, 2012 at 2:28 AM, Tom Lane wrote:
>> 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
On Thu, Aug 9, 2012 at 3:05 AM, Tom Lane wrote:
> ... btw, I think there is another problem here, which is that
> generate_wildcard_trgm will restart get_wildcard_part at the
> same place that the second loop exits, which means it would
> do the wrong thing if what it returns is a pointer to the
>
On Thu, Aug 9, 2012 at 2:28 AM, Tom Lane wrote:
> Fujii Masao 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
... btw, I think there is another problem here, which is that
generate_wildcard_trgm will restart get_wildcard_part at the
same place that the second loop exits, which means it would
do the wrong thing if what it returns is a pointer to the
second char of an escape pair. Consider for instance
Fujii Masao 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 (
Hi,
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? Here is the test case:
---
CREATE EXTENSION pg_trgm;
CREATE TABLE tbl (col text);
CREATE I
12 matches
Mail list logo
