Re: Logical Implication

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Vik Fearing <vik(at)postgresfriends(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Logical Implication
Date: 2026-09-11 14:10:55
Message-ID: aqQL78v7jr0AED_b@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 11, 2026 at 03:35:57PM +0200, Vik Fearing wrote:
> I would like to intruduce an IMPLIES operator for booleans that reads better
> than its developed formula.  That is, I think
>
>     a IMPLIES b
>
> is better in CHECK constraints and elsewhere than
>
>     NOT a OR b

I am probably not the target audience for a feature like this, but I'm not
sure I find the proposed new syntax to be substantially more readable. For
example, something like

NOT shipped OR shipped_date IS NOT NULL

would translate to

shipped IMPLIES shipped_date IS NOT NULL

In my head, I read the first as something like "either the package is not
shipped or the shipping date is set," and the latter as "if the package is
shipped then the shipping date is set." So I guess that does save me one
round of negation; ISTM that's the main benefit.

> It does not survive a round trip which has precedence with IN being changed
> to =ANY, BETWEEN changing to <= and >= (BETWEEN SYMMETRIC is even worse),
> etc; so I don't think that is a problem.

Even though there may be precedence, I think the proposal would be
strengthened by teaching it to survive the round trip. Since the benefit
is readability, presumably it would be useful in situations where you're
reading a CHECK constraint that someone else wrote.

--
nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-09-11 14:23:01 Re: pg_get_*_ddl() needs a redesign
Previous Message Robert Haas 2026-09-11 14:08:35 Re: pg_get_*_ddl() needs a redesign