Tomas Vondra <tomas.von...@enterprisedb.com> writes:
> I honestly don't know if this is the correct solution. It seems to me
> handling this at the EXPLAIN level might just mask the issue - it's not
> clear to me why adding "indexqualorig" would remove the ambiguity (if
> there's one). Perhaps it might be better to find why the ruleutils.c
> code thinks the OPERATOR() is necessary, and then improve/fix that?
As Masahiro-san already said, the root cause is that the planner
removes the RelabelType that is on the indexed variable. So ruleutils
sees that the operator is not the one that would be chosen by the
parser given those input expressions (cf generate_operator_name)
and it concludes it'd better schema-qualify the operator. While
that doesn't really make any difference in this particular case,
it is the right thing in typical rule-deparsing cases.
I don't think this output is really wrong, and I'm not in favor
of adding nontrivial overhead to make it better, so I don't like
the proposed patch. Maybe generate_operator_name could use some
other heuristic, but I'm unsure what. The case it wants to cover
is that the operator is in the search path but is masked by some
operator in an earlier schema, so simply testing if the operator's
schema is in the path at all would be insufficient.
regards, tom lane
