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.
