| From: | jian he <jian(dot)universality(at)gmail(dot)com> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Amul Sul <sulamul(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions |
| Date: | 2026-03-21 08:16:07 |
| Message-ID: | CACJufxFkLLuX1VJ-J3fppCr37PHtxkvwyd_e4zNd+VYK0v0gnQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 20, 2026 at 4:15 PM jian he <jian(dot)universality(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ls7777 | 2026-03-21 08:59:11 | Re: Patch for migration of the pg_commit_ts directory |
| Previous Message | SATYANARAYANA NARLAPURAM | 2026-03-21 08:15:54 | Re: log XLogPrefetch stats at end of recovery |