Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
От | Teodor Sigaev |
---|---|
Тема | Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? |
Дата | |
Msg-id | 576403FC.8000702@sigaev.ru обсуждение исходный текст |
Ответ на | Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
|
Список | 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 по дате отправления: