On Fri, 11 Sept 2026 at 14:36, Vik Fearing <[email protected]> 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
