Hi Joachim Thanks for sharing your thoughts
> However, it would > be useful to have alternate predicates that employ ternary logic, i.e. > equal3 and notEqual3 (which would need to return TRUE/FALSE/UNKNOWN so you > can have and3, or3, not3 etc.). Yes, that's another option, to just "overload" the actual methods in order to force ternary logic to be rendered. 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. 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" Maybe the whole jOOQ API could be reviewed for applicability of a distinction between ternary SQL logic and "Java" logic Cheers Lukas
