Hi Jian, Thanks for the patch and also for the offlist heads-up.
I agree with rejecting cases where the DEFAULT clause’s collation does not match the RETURNING collation. The result collation for json_value should come from the RETURNING clause if it has an explicit COLLATE, otherwise from the RETURNING type’s collation, and both the extracted value source (the value obtained from the JSON path when it matches) and the DEFAULT source should match it. I would not add a T_CollateExpr arm to exprSetCollation(). CollateExpr is just a transient wrapper that the planner rewrites to RelabelType, so it does not make sense to stamp it with a result collation there. Instead, transformJsonBehavior() should check if a source expression is a CollateExpr, verify that its collOid matches the target collation, and either keep it as is (no stamping needed if the collOid already matches the target) or strip the wrapper and stamp the inner node with exprSetCollation() if you need the inner node itself to carry the target collation. That is my current understanding of how exprSetCollation works, but I will confirm when I can check the code on my computer next week. Someone like Tom can correct me if I have missed something in the meantime. Thanks, Amit Langote
