Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions - Mailing list pgsql-hackers

On Fri, Mar 20, 2026 at 4:15 PM jian he <jian.universality@gmail.com> wrote:
>
> Handling SafeTypeCastExpr->castexpr within eval_const_expressions_mutator is
> tricky. However, if it is a FuncExpr node, we can attempt to fold its arguments
> (FuncExpr->args).
> (Not doing anything for SafeTypeCastExpr->castexpr is easier).

Just found out that eval_const_expressions_mutator should either
return a Const or recurse to every node field.
If not, the node field may have a COLLATE expression, and
ExecInitExprRec cannot cope with T_CollateExpr. For example:

SELECT CAST('1' collate "C" || 'h' AS text DEFAULT 'fallback' ON
CONVERSION ERROR);
ERROR:  unrecognized node type: 32

Therefore in eval_const_expressions, we cannot skip constant folding
SafeTypeCastExpr->castexpr.
Since eval_const_expressions_mutator is not error-safe, an
ErrorSaveContext pointer was added to eval_const_expressions_context.
It's initialized to NULL, and it will be passed as
``makeNode(ErrorSaveContext)`` inside T_SafeTypeCastExpr.


Previously in [0], I mentioned that SafeTypeCastExpr->castexpr can be FuncExpr,
CollateExpr, CoerceToDomain, ArrayCoerceExpr, or CoerceViaIO or others.

Constant folding in eval_const_expressions for these nodes are
generally processed
through the simplify_function -> evaluate_function -> evaluate_expr.
evaluate_expr can process it in an error-safe manner because the escontext
(ErrorSaveContext) within eval_const_expressions_context is properly populated.

SafeTypeCastExpr->castexpr can also be any Node type if the parse transformed
source expression is the same type as the target type. See
transformTypeCast->coerce_to_target_type_extended->coerce_type_extended:
```
    if (targetTypeId == inputTypeId ||
        node == NULL)
    {
        /* no conversion needed */
        return node;
    }
```
However, if SafeTypeCastExpr->castexpr is the same as
SafeTypeCastExpr->source then
eval_const_expressions premature failure at "source" should be not a
big problem for us.

Since castexpr is evaluated safely in most cases during eval_const_expressions,
I am not too worried about a premature failure occurring with CAST ... DEFAULT."

[0]: https://postgr.es/m/CACJufxHw9Y3fvh+rZj4ukLo=v54Dpafzk7Xvee_wi9zFZ6pOfg@mail.gmail.com

----------------------------------------------------------------
SELECT CAST(1 as date DEFAULT NULL ON CONVERSION ERROR) as a;

transformTypeCast->coerce_to_target_type->coerce_to_target_type_extended
will make SafeTypeCastExpr->castexpr as NULL.
To deparse the above, we need to save the transformed TypeCast->arg.
Therefore, SafeTypeCastExpr->source is necessary.



--
jian
https://www.enterprisedb.com/