pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17125: Operator precedence bug in websearch_to_tsquery function
3+ messages / 3 participants
[nested] [flat]
* BUG #17125: Operator precedence bug in websearch_to_tsquery function
@ 2021-07-28 01:39 PG Bug reporting form <noreply@postgresql.org>
2021-07-28 13:40 ` Re: BUG #17125: Operator precedence bug in websearch_to_tsquery function David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: PG Bug reporting form @ 2021-07-28 01:39 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: tim.connolly@oovvuu.com
The following bug has been logged on the website:
Bug reference: 17125
Logged by: Tim Connolly
Email address: tim.connolly@oovvuu.com
PostgreSQL version: 11.12
Operating system: Alpine Linux
Description:
Expectation: A web-search query of 'foo bar or baz' should match documents
that contain 'foo' and 'bar', and documents that contain 'foo' and 'baz'.
postgres=# select to_tsvector('english', 'baz') @@
websearch_to_tsquery('english', 'foo bar or baz ');
?column?
----------
t
(1 row)
Expected: f
postgres=# select websearch_to_tsquery('english', 'foo bar or baz');
websearch_to_tsquery
-----------------------
'foo' & 'bar' | 'baz'
(1 row)
Expected: 'foo' & ('bar' | 'baz')
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17125: Operator precedence bug in websearch_to_tsquery function
2021-07-28 01:39 BUG #17125: Operator precedence bug in websearch_to_tsquery function PG Bug reporting form <noreply@postgresql.org>
@ 2021-07-28 13:40 ` David G. Johnston <david.g.johnston@gmail.com>
2021-07-28 14:13 ` Re: BUG #17125: Operator precedence bug in websearch_to_tsquery function Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: David G. Johnston @ 2021-07-28 13:40 UTC (permalink / raw)
To: tim.connolly@oovvuu.com <tim.connolly@oovvuu.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Tuesday, July 27, 2021, PG Bug reporting form <noreply@postgresql.org>
wrote:
>
> postgres=# select websearch_to_tsquery('english', 'foo bar or baz');
> websearch_to_tsquery
> -----------------------
> 'foo' & 'bar' | 'baz'
> (1 row)
>
> Expected: 'foo' & ('bar' | 'baz')
>
>
The documentation describes the operator precedence and it isn’t what you
expect.
https://www.postgresql.org/docs/current/datatype-textsearch.html#DATATYPE-TSQUERY
David J.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17125: Operator precedence bug in websearch_to_tsquery function
2021-07-28 01:39 BUG #17125: Operator precedence bug in websearch_to_tsquery function PG Bug reporting form <noreply@postgresql.org>
2021-07-28 13:40 ` Re: BUG #17125: Operator precedence bug in websearch_to_tsquery function David G. Johnston <david.g.johnston@gmail.com>
@ 2021-07-28 14:13 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2021-07-28 14:13 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: tim.connolly@oovvuu.com <tim.connolly@oovvuu.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Tuesday, July 27, 2021, PG Bug reporting form <noreply@postgresql.org>
> wrote:
>> postgres=# select websearch_to_tsquery('english', 'foo bar or baz');
>> websearch_to_tsquery
>> -----------------------
>> 'foo' & 'bar' | 'baz'
>> (1 row)
>>
>> Expected: 'foo' & ('bar' | 'baz')
> The documentation describes the operator precedence and it isn’t what you
> expect.
It does appear from what I could find on the web that Google does it
the other way. Whether that's enough reason to change a behavior
that's stood since v11 is hard to say. We're not trying to be
entirely bug-compatible with Google here ... and even if we were,
who's to say whether they might not change this tomorrow?
Perhaps a more useful way to think about it is whether it's possible
to get the behavior opposite to the default. AFAICS there isn't any
way to get 'a & (b | c)' out of websearch_to_tsquery. However, if
we changed the default precedence, then there'd be no way to get the
old behavior, which is not nice at all. I first thought that maybe
you could write '"a b" or c', but that produces 'a <-> b | c' which
isn't the same.
Anyway, given that most people probably have no idea about this fine
point, I doubt that the benefits of changing it would outweigh the
costs.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2021-07-28 14:13 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-07-28 01:39 BUG #17125: Operator precedence bug in websearch_to_tsquery function PG Bug reporting form <noreply@postgresql.org>
2021-07-28 13:40 ` David G. Johnston <david.g.johnston@gmail.com>
2021-07-28 14:13 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox