| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
| Subject: | Re: Logical Implication |
| Date: | 2026-10-06 18:19:31 |
| Message-ID: | asU7s4y_QzU7yJVZ@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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!
> <acronym>SQL</acronym> uses a three-valued logic system with true,
> - false, and <literal>null</literal>, which represents <quote>unknown</quote>.
> - Observe the following truth tables:
> + false, and unknown; the null value of a <type>boolean</type> 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.
> <para>
> The operators <literal>AND</literal> and <literal>OR</literal> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-10-06 18:26:00 | Re: [PATCH] Fix segmentation fault caused by reentrancy in RI_Fkey_cascade_del (ri_triggers.c) |
| Previous Message | Jeff Davis | 2026-10-06 17:56:54 | Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators |