> This might be better than introducing a new setting for two reasons: > > 1. Settings are always obscure > 2. Settings are global to a query. You cannot mix behaviour within a query, > then.
Yep, a per-query setting would be bad. Sometimes you want binary and ternary logic within the same query. > Right now, only equal/eq and notEqual/ne are affected from this > (Java way of thinking) feature. Other methods behave in the SQL way, > i.e. as you put it, "and" is in fact "and3" Well, as long as the primitives are binary, this doesn't matter. So I guess the logical operators (and, or, not) don't need a binary-vs-ternary distinction after all. > Maybe the whole jOOQ API could be reviewed for applicability of > a distinction between ternary SQL logic and "Java" logic That would certainly be good. Some thoughts for that avenue, probably incomplete, in no particular order: Ternary logic and/or/not is compatible with binary, no separate API required. 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. 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). Ordered comparisons ( < > BETWEEN ) against NULLs tend to have three variants: UNKNOWN, NULLS FIRST, NULLS LAST. Not sure how to deal with user-defined functions. Probably nothing can be done. Maybe there isn't an issue anyway.
