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

On Wed, Mar 18, 2026 at 11:11 AM Corey Huinker <corey.huinker@gmail.com> wrote:
>>
>> + if (inputElementBaseType == MONEYOID ||
>> + targetElementBaseType == MONEYOID ||
>> + (inputElementBaseType == CIRCLEOID &&
>> + targetElementBaseType == POLYGONOID))
>> + {
>> + errorsafe_coercion = false;
>> + }
>
> What if we just reject cast functions with a non-null prosqlbody?
>

src/include/access/transam.h
 *        OIDs 12000-16383 are reserved for unpinned objects created by initdb's
 *        post-bootstrap processing.  initdb forces the OID generator up to
 *        12000 as soon as it's made the pinned objects it's responsible for.
Based on the above comments, I think comparing FirstUnpinnedObjectId
should be enough.

Rebased because of commit:
https://git.postgresql.org/cgit/postgresql.git/commit/?id=ba21f5bf8aff277aa1659a51d26109e0914df182
which add casting between bytea and uuid.

ExecInitFunc now always sets fcinfo->context from state->escontext
```
InitFunctionCallInfoData(*fcinfo, flinfo,
                         nargs, inputcollid,
                         (Node *) state->escontext, NULL);
```
This change in `ExecInitFunc` means **all** FuncExpr evaluations within a
SafeTypeCastExpr context will have their `fcinfo->context` set to the
`ErrorSaveContext`. This is by design for cast functions, but could
accidentally affect non-cast functions that appear in the cast expression
tree and happen to check `fcinfo->context`.

FunctionCallInfoBaseData->context is a generic poiner, it canbe other
than ErrorSaveContext.
For example, in ExecCallTriggerFunc we have:
```
    InitFunctionCallInfoData(*fcinfo, finfo, 0,
                             InvalidOid, (Node *) trigdata, NULL);
```
Because of this, we must differentiate our FuncExpr nodes. Soft-error evaluation
should be only for FuncExpr nodes produced by build_coercion_expression.

We can add a boolean (errorsafe) flag directly to the FuncExpr struct.
This flag to indicate whether this specific expression should be evaluated in an
error-safe manner. In the future, we can also use this flag for

CAST(expr AS type FORMAT 'template' DEFAULT defexpr ON CONVERSION ERROR)

In build_coercion_expression, we set FuncExpr->errorsafe if the specific cast
function needs to be evaluated in an error-safe manner.
build_coercion_expression is also
used in other callers, such as coerce_type_typmod, coerce_to_domain,
that means more refactoring in parse_coerce.c.

V21-0022 JIT related change is totally wrong.
Matheus Alcantara <matheusssilv97@gmail.com> helped me resolve the JIT issue.
Previously, I wasn't using SET jit_above_cost = 0; to properly
exercise the JIT-related tests.

You mentioned refactoring RangeVarGetRelidExtended in [1],
With a hint from Andrew Dunstan, we can actually reduce the code
duplication, see v22-0004.
[1] https://postgr.es/m/CADkLM=cZ7N+f4Bj-8MiccFcTASjBB2r1_s3BD9OFbbQOwK01cg@mail.gmail.com


As mentioned before, FunctionCallInfoBaseData->context can be other
Node other than ErrorSaveContext.
Therefore for geometry error safe refactoring, we must pass NULL, not
fcinfo->context, for non-cast realted function.
For example, function point_add_point within box_add, the third
parameter should be NULL, not fcinfo->context.

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).