Re: Logical Implication

Hi Nathan,

Thanks for taking a look at it.

On 11/09/2026 16:10, Nathan Bossart wrote:
> 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.

Yes. To me, the latter is more intuitive.

>> 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.

Perhaps. There is also the precedent of LIKE coming back as ~~ which I
think is a lot worse than getting NOT a OR b  instead of a IMPLIES b.  I
am happy to do the work to round trip IMPLIES but I will wait for more
opinions before I do so.  My own opinion is that it's not worth it.

--

Vik Fearing