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/
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) |