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
