Обсуждение: [BUGS] BUG #14515: tsquery with only a negative term doesn't match emptytsvector

Поиск
Список
Период
Сортировка

[BUGS] BUG #14515: tsquery with only a negative term doesn't match emptytsvector

От
pgsql@tomd.cc
Дата:
The following bug has been logged on the website:

Bug reference:      14515
Logged by:          Tom Dunstan
Email address:      pgsql@tomd.cc
PostgreSQL version: 9.5.5
Operating system:   Linux
Description:

Hi all

Not sure if this is a bug or just ambiguity in the docs, but I certainly
found it counter-intuitive.

Basically while `select 'somethingelse'::tsvector @@ '!foo'::tsquery`
returns true, `select ''::tsvector @@ '!foo'::tsquery` returns false, which
was surprising to me.

I would expect a tsvector (empty or not) that doesn't contain foo to match
!foo.

It seems like the behaviour is "match a term that isn't foo" rather than
"match if no terms match foo".

Not sure if this is intentional (in which case maybe the docs could be a bit
more clear) or if it's just a bug. IMO the former behaviour isn't very
useful as it forces us to either code around it by writing extra SQL to
handle the case, or insert a dummy term to match against. Neither is very
nice.

It may be unintentional: there's a fast-path out of the match function here

https://github.com/postgres/postgres/blob/f21a563d25dbae153937aec062161184189478b8/src/backend/utils/adt/tsvector_op.c#L1930-L1935
that returns false when the vector is empty. Perhaps it just wasn't taking
the negative-only case into account.

Cheers

Tom



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14515: tsquery with only a negative term doesn't match empty tsvector

От
Tom Lane
Дата:
pgsql@tomd.cc writes:
> Basically while `select 'somethingelse'::tsvector @@ '!foo'::tsquery`
> returns true, `select ''::tsvector @@ '!foo'::tsquery` returns false, which
> was surprising to me.

Not sure about this.  A plausible reading of '!foo' is "there is a lexeme
that is not foo".  But even if that was Oleg & Teodor's intention,
I would not want to swear that the tsquery stuff is totally consistent
about it ...

            regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14515: tsquery with only a negative term doesn't match empty tsvector

От
Tom Lane
Дата:
I wrote:
> pgsql@tomd.cc writes:
>> Basically while `select 'somethingelse'::tsvector @@ '!foo'::tsquery`
>> returns true, `select ''::tsvector @@ '!foo'::tsquery` returns false, which
>> was surprising to me.

> Not sure about this.  A plausible reading of '!foo' is "there is a lexeme
> that is not foo".  But even if that was Oleg & Teodor's intention,
> I would not want to swear that the tsquery stuff is totally consistent
> about it ...

After further poking at it, I found that a GIN index search will return
empty tsvectors, matching your expectation!  So indeed we are being
inconsistent, which means that there is certainly a bug here no matter
which interpretation you favor.

Also, while a GIST index search doesn't return empty entries, it turns
out that that's only because it always applies recheck, so that the
fast-path exit in ts_match_vq() is what's rejecting the empty value
in that case too.

Otherwise, it seems pretty clear to me that the interpretation (most of?)
the code is using is that "!foo" means "foo does not appear in the value".

A look around at other callers of TS_execute indicate that none of the
rest of them are trying to "optimize" empty value, only empty query.

In short, I now agree both that this is a bug, and that you've correctly
identified the cause.  Will patch.

            regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14515: tsquery with only a negative term doesn't match empty tsvector

От
Tom Dunstan
Дата:
> On 27 Jan 2017, at 2:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> In short, I now agree both that this is a bug, and that you've correctly
> identified the cause.  Will patch.

Thanks Tom!



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs