AFAICS, we have the following problem constructions: ================================ a IS DISTINCT FROM b a IS NOT DISTINCT FROM b a IN (...) a NOT IN (...) CASE a WHEN b THEN ... ELSE d END NULLIF(a, b) JOIN USING / NATURAL JOIN ================================
As a quick recap, the following options are available to us. 1) Add the "USING operator" clause. Rejected due to: * Non-standard syntax. * ruleutils.c could not safely convert this back to the source text. * In case "IS DISTINCT FROM" on composite types, using only the eq operator is maybe not enough. 2) Using default btree opclass/opfamily operators. Rejected due to: * Adding yet another way of selecting an operator to the existingfunc_select_candidate and opfamily seems too complicated and not safe. * May not work in some cases. 3) CVE-2018-1058 revert. Rejected due to obvious reasons. In my humble opinion, the best way to solve an issue is (1). Whether it's even worth it. Although it uses non-standard syntax, it does not break the existing one. -- Best regards, Maxim Orlov.
