Re: Logical Implication

I spent some time looking at this one from a few different angles.

* NULL behavior: while not a conscious decision of your patch, a straight
translation of "a IMPLIES b" to "NOT a OR b" would settle the standard on
Kleene logic for material implication [0]. I think that's okay; IIUC that
would be the case for any popular SQL database that implements it in a
similar fashion. According to Wikipedia, SQL uses "a comment fragment of
the Kleene and Łukasiewicz three-valued logic (which differ in their
definition of implication; however, SQL defines no such operation)" [1].
This proposal changes that, so it seems worth calling out.

* The name: it's hard to imagine another name for this operation.
"implies" is pretty commonly used for material implication in other
languages, and it reads nicely, so I have no concerns here.

* Short circuiting: IIUC the new IMPLIES operation wouldn't be guaranteed
to short-circuit, which matches the behavior of AND and OR and thus is
probably fine.

* Past discussion: I only found a very brief past discussion about this
that quickly veered into a discussion about exclusive-OR [2].

* Precedence: Placing it below OR seems to be pretty common, so no concerns
there. I don't know where it belongs in relation to INTERSECT, UNION, or
EXCEPT, though. Any thoughts about that?

* Associativity: The proposal chooses right associativity. I thought about
this part the most, and I'm not sure any associativity is desirable. I
think we should forbid chained implications for two reasons: 1) if we do it
one way and the SQL committee chooses the other, we're in a tight spot, and
2) I cannot come up with any natural examples to illustrate the desired
behavior. Take the following example:

shipped IMPLIES zip code set IMPLIES ship date in the past

Under right associativity, this would translate to

NOT shipped OR NOT zip code set OR ship date in the past

The former reads as "if shipped, then the zip code is set and the ship date
is in the past", but the latter is pretty obviously not that. If "shipped"
is true and "zip code" is not set, it would return true, for example.
Granted, the user probably should have written

shipped IMPLIES (zip code set AND ship date in the past)

but that feels like an easy mistake to make, at least to me. I'm not sure
left associativity is any better in this regard.

On Fri, Sep 11, 2026 at 06:12:51PM +0200, Vik Fearing wrote:
> On 11/09/2026 16:10, Nathan Bossart wrote:
>> On Fri, Sep 11, 2026 at 03:35:57PM +0200, Vik Fearing wrote:
>>> 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.

I'm fine with leaving that out for now.

[0] https://en.wikipedia.org/wiki/Three-valued_logic#Kleene_and_Priest_logics
[1] https://en.wikipedia.org/wiki/Null_(SQL)#Comparisons_with_NULL_and_the_three-valued_logic_(3VL)
[2] https://postgr.es/m/flat/61B8D172-D35A-4715-A793-6EFDD2795E5D%40epcylon.com

--
nathan