Date: Fri, 11 Sep 2026 09:10:55 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Vik Fearing <vik@postgresfriends.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Logical Implication
Message-ID: <aqQL78v7jr0AED_b@nathan>
References: <37c76707-e6fa-4ee3-b57f-aa0bf1b0bba8@postgresfriends.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <37c76707-e6fa-4ee3-b57f-aa0bf1b0bba8@postgresfriends.org>
Archived-At: <https://www.postgresql.org/message-id/aqQL78v7jr0AED_b%40nathan>
Precedence: bulk

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