> Ternary logic and/or/not is compatible with binary, no separate API required.
Hmm, as a matter of fact, SQL:2008 specifies the following truth tables: Table 11 — Truth table for the AND boolean operator AND True False Unknown True True False Unknown False False False False Unknown Unknown False Unknown Table 12 — Truth table for the OR boolean operator OR True False Unknown True True True True False True False Unknown Unknown True Unknown Unknown Table 13 — Truth table for the IS boolean operator IS TRUE FALSE UNKNOWN True True False False False False True False Unknown False False True So, there really is some consideration to be done in that area as well... However, not all databases actually implement the boolean data type, so for many databases, the above table doesn't really apply > Aggregate functions generally ignore nulls. I can't think of a binary-vs-ternary semantic distinction that would make any sense, so that part of the API can be left as is. It could be relevant to GROUP_CONCAT(), LISTAGG() and similar (ordered) aggregate functions. > I'm not sure about IN and NOT IN (I have no idea what a typical database does if the set of values contains a NULL). Yes, NOT IN is the most tricky one. 1 NOT IN (NULL, 1) returns false (or more correctly, returns NULL). I had recently posted a blog post about this, and how it isn't handled correctly (the ternary way) in all databases: http://blog.jooq.org/2012/01/27/sql-incompatibilities-not-in-and-null-values/ As soon as you have NULL in the right hand side of the NOT IN predicate, you'll always get NULL as a result. For the IN predicate, however, NULL is irrelevant. > Ordered comparisons ( < > BETWEEN ) against NULLs tend to have three variants: UNKNOWN, NULLS FIRST, NULLS LAST. Same here. I'm pretty sure, the SQL standard defines UNKNWON to be the only correct outcome of such comparisons. But some databases may have different views on the subject. > Not sure how to deal with user-defined functions. Probably nothing can be done. Maybe there isn't an issue anyway. Yes, I don't think there's an issue here. Thanks for your thoughts. I'll do some thinking on my side, too.
