Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
Date
Msg-id 576403FC.8000702@sigaev.ru
Whole thread Raw
In response to Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
List pgsql-hackers

Tom Lane wrote:
> Teodor Sigaev <teodor@sigaev.ru> writes:
>>> So I think there's a reasonable case for decreeing that <N> should only
>>> match lexemes *exactly* N apart.  If we did that, we would no longer have
>>> the misbehavior that Jean-Pierre is complaining about, and we'd not need
>>> to argue about whether <0> needs to be treated specially.
>
>> Agree, seems that's easy to change.
>> ...
>> Patch is attached
>
> Hmm, couldn't the loop logic be simplified a great deal if this is the
> definition?  Or are you leaving it like that with the idea that we might
> later introduce another operator with the less-than-or-equal behavior?

Do you suggest something like merge join of two sorted lists? ie:

while(Rpos < Rdata.pos + Rdata.npos && Lpos < Ldata.pos + Ldata.npos)
{if (*Lpos > *Rpos)    Rpos++;else if (*Lpos < *Rpos){    if (*Rpos - *Lpos == distance)        match!    Lpos++;}else{
  if (distance == 0)        match!    Lpos++; Rpos++;}
 
}

Such algorithm finds closest pair of (Lpos, Rpos) but satisfying pair could be 
not closest, example: to_tsvector('simple', '1 2 1 2') @@ '1 <3> 2';

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Restriction of windows functions
Next
From: Tom Lane
Date:
Subject: Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?