Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xE9mN-00000000wvT-3zTo for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Oct 2026 18:20:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xE9lL-000000013kE-2rG7 for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Oct 2026 18:19:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xE9lL-000000013k6-1hCO for pgsql-hackers@lists.postgresql.org; Tue, 06 Oct 2026 18:19:39 +0000 Received: from mail-qv1-xf2e.google.com ([2607:f8b0:4864:20::f2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xE9lI-00000000kmt-3twH for pgsql-hackers@lists.postgresql.org; Tue, 06 Oct 2026 18:19:38 +0000 Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-917a64f28d0so13297056d6.0 for ; Tue, 06 Oct 2026 11:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791310775; x=1791915575; darn=lists.postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=36mSqzrEMJNN48uf3rVP9hv7nKNG3xttljpfbgSETdA=; b=GKnRKmNkUT4vZZw8tZMJKIiC6aAnJYNVM9LKKkN2FMkeWgfhkHua7Ck2vhAzRolhvC yEb5xtAYNGJEwAJS01j8rh2y5iqtSyQ00d3ikmwGYH7JCJAq6wSMDnzp4YBhDHv2pAtW kmtmvbU1vgsrcOz9wMdsWfF5sCkcvdy3wAG6kNRiQk18mHWgLXbvwsgLZR39gjpPJ3kR TnqX8DEr+tiuIdfRxWZycDblS9hxiaXlajgWQ6m74YABtKDGpAUoh1CBVvP0Cun9av+e wN2KlFVeg6ScNRVUcOl4DaXE430lMzlLwZ4/AbI6L1WJ9suVV33nOza68YqNbhVxI+gw vXkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791310775; x=1791915575; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=36mSqzrEMJNN48uf3rVP9hv7nKNG3xttljpfbgSETdA=; b=BGvQsYHsOVxvt5DMlXHEM8wLVPP6psDIT/t1Kr5nwySIe9ORwp9UfKLbd9yLXPanKm pbMJf0E0sq5O5B2L7NgWABv7aIhoar3w+WjqtMMQx9sprnqjioBzkf/DmG1EF5EY4O5W /2X7o2vEqv83OPnjdK7aHzQWDfgUw+bMbGF+Df4gqQG4ddDmXwbMTRwOREj1veVVnRQu seOmQRFzhcOKRfpGINj9ybXacPyKC15A2x7Ktw5JpF4MlTK2IbFhHukQ6aptOQVqFjsb ESQuQUaHEQcD0u+25aQ/TLT2RpO2VBHoBO+iL+RS3khZH+ExEW7OGcSjx/cixnMVYgCf zfWA== X-Forwarded-Encrypted: i=1; AKwUvByHwqUAQwFPoievXHaF1D/8XJkZvTYK533bXg1oMZRBAwBKQLjmkjMaXswshSaFrqeLfXG4CmnoUDL7oaBv@lists.postgresql.org X-Gm-Message-State: AFq9FYIZAFv3EW1t5xT+RdReD2lrilxLrgrh8cQWF8WNA2THWDwfmwvL bDxLYZy7TKJ6soUra0zHzM0zj+cdhXRe3JFbbZEsInVd1/We8+xa5xlY X-Gm-Gg: AYBFou0y1GrHHHyS0OwBKejBkRsnJsKLxDr34A5zlDXO61e2sSQ+SIosYhpQhoQQ2Yu H7c+J05UxZFiek8gq4mnX/SGvusgwLJ3s75+iMWGCywMC8fccaVpzAj9yBcZYKMREpS60zmN+r9 Khd3IIx5euDjACdxvFwbMU1G3O8tSnSu4fsNmxMi4KkvooytQYaAxjorK7KDo0hUObESCe4QubP DIffKh+5mIB0WyeOyxpMVj7eKAj2kxg4sBDlPmQFz8OhFi7JwICN/cB1mU67j8Ux8w9H4NhvDYA gFMixy7/JR+nbPr2c26BgQv/CVjwF/CXUoyLFJnakMhLLMvOTt93E9kVwsF5+mB222Uy7zAhqVf l6e/0uCgjap2aaRSUl5PZ/odexp1OD7app9eu42hPEsWtrlJ0Zj/Lhh/COMCbBy3zbwOzUHIgSi sTCKL7+z5497HZAcy6Poe+n+xmg0caQ5/LjaJc7PMKnuFb5EEAe/hMnPx9S6hWCE51v88P/sGGM UG0Us6sKMf0Cv5jlmOdGmrEOSz+afRRQhI02FSjGxdSx8RYvTmfLLXp+YIY6mVcko6pmvuzXG7t 8ALjgN9GegrWbdzeF9oWDZgG0g== X-Received: by 2002:a05:6214:2385:b0:914:4c57:5103 with SMTP id 6a1803df08f44-91985811615mr72679976d6.8.1791310775231; Tue, 06 Oct 2026 11:19:35 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91996130376sm1861436d6.13.2026.10.06.11.19.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2026 11:19:34 -0700 (PDT) Date: Tue, 6 Oct 2026 13:19:31 -0500 From: Nathan Bossart To: Vik Fearing Cc: Zsolt Parragi , pgsql-hackers@lists.postgresql.org, Jacob Champion , Isaac Morland Subject: Re: Logical Implication Message-ID: References: <37c76707-e6fa-4ee3-b57f-aa0bf1b0bba8@postgresfriends.org> <9ab35dbb-d9a4-4c1e-bae2-7763ddeb720c@postgresfriends.org> <3d779ee0-6596-4dae-b79c-e35b237f83bf@postgresfriends.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Oct 03, 2026 at 06:18:43PM +0200, Vik Fearing wrote: > Attached is a new patch set that makes IMPLIES non-associative, changes the > tests, and also survives a round trip.  I put the latter in a separate patch > in case it isn't wanted after all. Thanks! > SQL uses a three-valued logic system with true, > - false, and null, which represents unknown. > - Observe the following truth tables: > + false, and unknown; the null value of a boolean and the truth > + value unknown are one and the same. In the truth tables below the left > + operand of a binary operator selects the row, and the right operand the > + column: I find the reorganization to be an improvement, and I intend to commit this one sooner than later. The only thing I'd change is the switch from NULL to "unknown" in the tables. Users deal with NULL at the command level, and the rest of the docs use NULL, so I think the existing text has the right idea by noting once that NULL represents "unknown" and then using NULL throughout. > > The operators AND and OR are > commutative, that is, you can switch the left and right operands > without affecting the result. (However, it is not guaranteed that This part goes on to mention that there is no guaranteed evaluation order for AND and OR. Maybe it should mention IMPLIES, too. > + case IMPLIES_EXPR: > + > + /* > + * The planner normally expands this, but in case > + * it didn't, evaluate it as NOT a OR b. The NOT > + * step doesn't jump, so it needs no adjusting. > + */ > + Assert(nargs == 2); IMHO this and the postgres_fdw equivalent should be replaced with elog(ERROR, ...) instead. Otherwise, they'll be untested dead code that mask problems elsewhere. For the tests, I'd probably trim those down a bit to what feels essential. For example, we probably don't need to test that IMPLIES is unreserved. I'll handle this part. Note to self: this will need a catversion bump. -- nathan