Re: Logical Implication

On Fri, 11 Sept 2026 at 14:36, Vik Fearing <vik(at)postgresfriends(dot)org> wrote:
>
> Hi.
>
>
> 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 plan on submitting this to the SQL committee as well, but I've learned
> that they like an implementation to have it first, and I cannot imagine
> that they would quibble over the keyword used.
>
>
> The first patch is a restructure of the documentation for NOT/AND/OR
> because IMPLIES is not symmetric about the diagonal and I didn't want it
> to stand out like a sore thumb. The second patch is the actual
> implementation.
>
>
> 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.

What behaviour should be expected for the following cases:

a IMPLIES b IMPLIES c

CHECK (a IMPLIES b) -- where b is NULL
-- And what does that deparse to?

a IMPLIES (100 / b > 10)

Thom