Skip site navigation (1) Skip section navigation (2)

Re: Rethinking our fulltext phrase-search implementation

From: Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Rethinking our fulltext phrase-search implementation
Date: 2016-12-21 12:34:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hello Tom,

On 17.12.2016 21:36, Tom Lane wrote:
> 4. The transformations are wrong anyway.  The OR case I showed above is
> all right, but as I argued in <24331(dot)1480199636(at)sss(dot)pgh(dot)pa(dot)us>, the AND
> case is not:
> regression=# select 'a <-> (b & c)'::tsquery;
>           tsquery
> ---------------------------
>  'a' <-> 'b' & 'a' <-> 'c'
> (1 row)
> This matches 'a b a c', because 'a <-> b' and 'a <-> c' can each be
> matched at different places in that text; but it seems highly unlikely to
> me that that's what the writer of such a query wanted.  (If she did want
> that, she would write it that way to start with.)  NOT is not very nice
> either:

If I'm not mistaken PostgreSQL 9.6 and master with patch 
"fix-phrase-search.patch" return false for the query:

select 'a b a c' @@ 'a <-> (b & c)'::tsquery;
(1 row)

I agree that such query is confusing. Maybe it is better to return true 
for such queries?
Otherwise it seems that queries like 'a <-> (b & c)' will always return 
false. Then we need maybe some warning message.

Artur Zakirov
Postgres Professional:
Russian Postgres Company

In response to


pgsql-hackers by date

Next:From: Etsuro FujitaDate: 2016-12-21 12:44:01
Subject: Re: postgres_fdw bug in 9.6
Previous:From: Heikki LinnakangasDate: 2016-12-21 12:25:24
Subject: Re: Logical tape pause/resume

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group