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

On Wed, Mar 25, 2026 at 9:14 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:

> On Tue, Mar 24, 2026 at 9:13 PM Peter Eisentraut <peter(at)eisentraut(dot)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.
>

What if we just...didn't? The MONEY has been deprecated since 7.4. If we
simply didn't implement this, and someone attempted to use this cast with
default, what bad would happen?