Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m8kJd-0006gN-Tr for pgsql-bugs@arkaria.postgresql.org; Wed, 28 Jul 2021 14:13:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m8kJb-0005HH-8l for pgsql-bugs@arkaria.postgresql.org; Wed, 28 Jul 2021 14:13:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m8kJb-0005H8-2A for pgsql-bugs@lists.postgresql.org; Wed, 28 Jul 2021 14:13:43 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m8kJW-00070P-2h for pgsql-bugs@lists.postgresql.org; Wed, 28 Jul 2021 14:13:42 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 16SEDZZM575791; Wed, 28 Jul 2021 10:13:36 -0400 From: Tom Lane To: "David G. Johnston" cc: "tim.connolly@oovvuu.com" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #17125: Operator precedence bug in websearch_to_tsquery function In-reply-to: References: <17125-483838072f5f4bac@postgresql.org> Comments: In-reply-to "David G. Johnston" message dated "Wed, 28 Jul 2021 06:40:25 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <575789.1627481615.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 28 Jul 2021 10:13:35 -0400 Message-ID: <575790.1627481615@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Tuesday, July 27, 2021, PG Bug reporting form > 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