On Fri, Jan 23, 2026 at 10:40 PM Richard Guo <[email protected]> wrote: > I'm kind of concerned about whether there are edge cases where this > transformation is not safe, specifically regarding "rowtype" inputs.
After a second thought, I think this should be safe even for "rowtype" inputs. The executor (ExecInterpExpr) evaluates a DistinctExpr with non-null inputs by simply applying the underlying equality function and then negating the result. Also, record_eq explicitly treats two NULLs as equal. Therefore, in this case, converting IS DISTINCT FROM to the inequality operator in the planner produces the exact same behavior as the executor. Also, I think we can play this same trick with BooleanTest (IS [NOT] TRUE/FALSE/UNKNOWN). A BooleanTest treats a NULL input as the logical value "unknown". If we know that the input can not be NULL, we can simplify it directly to a boolean expression or a constant. Please see 0002. - Richard
v2-0001-Optimize-IS-DISTINCT-FROM-with-non-nullable-input.patch
Description: Binary data
v2-0002-Optimize-BooleanTest-with-non-nullable-input.patch
Description: Binary data
