On 14.11.23 17:15, Tom Lane wrote:
I don't love the patch details though. It seems entirely wrong to check
this before we check the opclass match.
Not sure why? The order doesn't seem to matter?
Also, in at least some cases
the code presses on looking for another match if the current opclass
doesn't match; you've broken such cases.
I see. That means we shouldn't raise an error on a mismatch but just do
if (key->partcollation[i] != collationIds[j])
continue;
and then let the existing error under if (!found) complain.
I suppose we could move that into the
if (get_opclass_opfamily_and_input_type(...))
block. I'm not sure I see the difference.
