On Tue, Mar 24, 2026 at 9:13 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> In patch 0012, I did not apply the changes involving
> float_*flow_error() in dtof(). These should be considered together
> with the error handling changes in patch 0018 (about which below).
>
> Patch 0004 is probably ok, I just need to study a bit more, since it's
> a bit different from the other ones.
>
> In the comment for patch 0008 you write that supporting soft errors in
> int4_cash() is not easy. I suppose this is because of the external
> function call to int8mul()? Maybe that was necessary in ancient
> times, but int8mul() is nowadays just a fmgr wrapper around
> pg_mul_s64_overflow(), which you can call directly in int4_cash(), and
> then it should be easy.
>
cash_numeric is not easy to refactor safely,
To do this, we have to refactor (numeric_round, numeric_div), which
will require refactoring more functions.
So CoercionErrorSafe_Internal still checks whether the source
element/base type is MONEYOID.
> About patch 0017 (jsonb): Calling ereturn() in a function that returns
> void, well, you make that work, but it seems a bit weird. Maybe
> cannotCastJsonbValue() could be changed to return a dummy datum, and
> then you could just call it like
>
> return cannotCastJsonbValue(...);
>
ok.
> Similarly, about patch 0018 (refactor float error): I think this is a
> fragile API. float_overflow_error() now will either ereport or just
> errsave. But nothing enforces that callers do the right thing. For
> example, in patch 0019, you change float_zero_divide_error(NULL) to
> float_zero_divide_error(escontext), but don't insert a return, so the
> code will continue to perform the division. Similar to patch 0017,
> maybe these functions should be changed to have a non-void return
> value. Or maybe make separate functions to be used in places where we
> want soft error handling.
>
Add argument to float_overflow_error, extern void
float_underflow_error, float_zero_divide_error
requires extensive refactoring.
So I have added
+extern float8 float_overflow_error_ext(struct Node *escontext);
+extern float8 float_underflow_error_ext(struct Node *escontext);
+extern float8 float_zero_divide_error_ext(struct Node *escontext);
> In the comment for patch 0021 you write that the function casting type
> circle to type polygon cannot be error safe, because it's a SQL
> language function. I suggest to convert this to a C function and make
> the required changes there.
>
Please see 007.
Now with this entire v24 patchset, the only built-in cast function
that is not error safe is numeric_cash.
I'll think about CREATE CAST ... WITH SAFE FUNCTION syntax, later.
Right now, I am still using CoercionErrorSafe_Internal to check if CAST DEFAULT
can be applied to this combination of source type and target type.
--
jian
https://www.enterprisedb.com/
