After several tests, I found that this patch do not fix the bug well.
I think we should use the same logic to treat parent CollateExpr and child
CollateExpr. In your patch, if the parent node is CollateExpr and the target
type is non-collatable, we coerce CollateExpr->arg. If the child node is
CollateExpr and the target type is non-collatable, we just skip.
Some types can be casted to another type even if type_is_collatable
returns false. Like bytea to int (It depends on the content of the string). If
we simply skip, bytea will never be casted to int even if the content is all
digits.So the attachment is my patch and it works well as far as I tested. ________________________________ 发件人: Tom Lane <[email protected]> 发送时间: 2021年4月13日 0:59 收件人: Yulin PEI <[email protected]> 抄送: [email protected] <[email protected]> 主题: Re: Core dump happens when execute sql CREATE VIEW v1(c1) AS (SELECT ('4' COLLATE "C")::INT FROM generate_series(1, 10)); Yulin PEI <[email protected]> writes: > I found it could cause a crash when executing sql statement: `CREATE VIEW > v1(c1) AS (SELECT ('4' COLLATE "C")::INT FROM generate_series(1, 10)); ` in > postgres 13.2 release. Nice catch. I don't think the code in DefineVirtualRelation is wrong: exprCollation shouldn't report any collation for an expression of a non-collatable type. Rather the problem is with an old kluge in coerce_type(), which will push a type coercion underneath a CollateExpr ... without any mind for the possibility that the coercion result isn't collatable. So the right fix is more or less the attached. regards, tom lane
fix-collation-coercion.patch
Description: fix-collation-coercion.patch
