| From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Logical Implication |
| Date: | 2026-09-29 16:40:42 |
| Message-ID: | CAMsGm5fatRFmUrcr9vCp5wHdbg2gTY=Av78sxsuHOxKD9B54uw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 29 Sept 2026 at 12:30, Jacob Champion <
jacob(dot)champion(at)enterprisedb(dot)com> wrote:
Either way, you don't really need to convince me; I just wanted to +1
> Nathan's "no associativity" idea and run away. And associative or not,
> IMPLIES is a lot nicer than the NOT-OR construction.
>
Probably good. I can easily imagine myself seeing a IMPLIES b IMPLIES c and
reading (a IMPLIES b) AND (b IMPLIES c) even though I know that's not how
Postgres operators work.
Personally, I currently spell IMPLIES as "<=" which would be about as good
as you could expect, except that the usual mathematical
implication operator visually appears much closer to "=>". Also any NULL
input at all results in NULL output even when interpreting the NULL as
"unknown" would result in a TRUE result.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rui Zhao | 2026-09-29 17:03:39 | Re: Extension security improvement: Add support for extensions with an owned schema |
| Previous Message | Greg Burd | 2026-09-29 16:31:39 | Re: [PATCH] Corruption Issue: Fix missing tts_tid in ExecForceStoreHeapTuple |