Re: fts, compond words?

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Mike Rylander <mrylander(at)gmail(dot)com>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, pgsql-general(at)postgresql(dot)org
Subject: Re: fts, compond words?
Date: 2005-12-07 17:33:17
Message-ID: 43971CDD.2080208@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

That is a long discussed thing. We can't formulate unconflicting rules... For
example:
1) a &[dist<=2] ( b &[dist<=3] c )
2) a &[dist<=2] ( b |[dist<=3] c )
3) a &[dist<=2] !c
4) a &[dist<=2] ( b |[dist<=3] !c )
5) a &[dist<=2] ( b & c )
What does exact they mean? What is tsvectors which should be matched by those
queries?

The simple solution is : under operation 'phrase search' (ok, it will be '+'
below) it must be only 'phrase search operations. I.e.:
a | b ( c + ( d + e ) ) - good
a | ( c + ( d & g ) ) - bad.

For example, we have word 'foonish' and after lexize we got two lexemes: 'foo1'
and 'foo2'. So a good query 'a + foonish' becomes 'a + ( foo1 | foo2 )'...

Mike Rylander wrote:
> On 12/6/05, Marcus Engene <mengpg(at)engene(dot)se> wrote:
>
> [snip]
>
>
>> A & (B | (New OperatorTheNextWordMustFollow York))
>>
>
>
> Actually, I love that idea. Oleg, would it be possible to create a
> tsquery operator that understands proximity? Or, how allowing a
> predicate to the current '&' op, as in '&[dist<=1]' meaning "next
> token follows with a max distance of 1". I imagine that it would
> only be useful on unstripped tsvectors, but if the lexem position is
> already stored ...
>
> --
> Mike Rylander
> mrylander(at)gmail(dot)com
> GPLS -- PINES Development
> Database Developer
> http://open-ils.org
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Axel Loder 2005-12-07 17:34:25 Re: [pgsql-de-allgemein] Query SELECT * sehr langsam
Previous Message Bruce Momjian 2005-12-07 17:31:11 Re: [GENERAL] Map of Postgresql Users (OT)