Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJhuL-0004Ha-FU for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Dec 2016 14:30:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cJhuK-0005uc-P0 for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Dec 2016 14:30:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cJhuJ-0005tp-KS for pgsql-hackers@postgreSQL.org; Wed, 21 Dec 2016 14:30:15 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cJhuG-00084R-Gk for pgsql-hackers@postgreSQL.org; Wed, 21 Dec 2016 14:30:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id uBLEU7Ar004362; Wed, 21 Dec 2016 09:30:07 -0500 From: Tom Lane To: Artur Zakirov cc: pgsql-hackers@postgreSQL.org Subject: Re: Rethinking our fulltext phrase-search implementation In-reply-to: <773bb687-1388-6c78-af23-5635a41a243d@postgrespro.ru> References: <28215.1481999808@sss.pgh.pa.us> <773bb687-1388-6c78-af23-5635a41a243d@postgrespro.ru> Comments: In-reply-to Artur Zakirov message dated "Wed, 21 Dec 2016 15:34:12 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4360.1482330607.1@sss.pgh.pa.us> Date: Wed, 21 Dec 2016 09:30:07 -0500 Message-ID: <4361.1482330607@sss.pgh.pa.us> X-Pg-Spam-Score: -5.0 (-----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Artur Zakirov writes: > Otherwise it seems that queries like 'a <-> (b & c)' will always return > false. Then we need maybe some warning message. Well, the query as written is pointless, but it could be useful with something other than "b" and "c" as the AND-ed terms. In this usage "&" is equivalent to "<0>", which we know has corner-case uses. I'm not inclined to issue any sort of warning for unsatisfiable queries. We don't issue a warning when a SQL WHERE condition collapses to constant FALSE, and that seems like exactly the same sort of situation. It strikes me though that the documentation should point this out. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers