MIME-Version: 1.0
References: 
 <CADkLM=fv1JfY4Ufa-jcwwNbjQixNViskQ8jZu3Tz_p656i_4hQ@mail.gmail.com>
 <CACJufxHGxB7KPAStUHZcWhFEDXsnU06qOugh60X4hHG6J-xoUA@mail.gmail.com>
 <CADkLM=f0xruKRH+6XvCsM1EVic9y4BL4AFo3VUfvRLdu-Qp5Gg@mail.gmail.com>
 <CADkLM=e4y2bLv-6_JY5c6vC9QtweW9VfxVmVJFpcriy8Rs23TA@mail.gmail.com>
 <CACJufxGO_qmyGjBvkwhCZzm6bWiqj8iyd1dGbL+_guok6yPMCQ@mail.gmail.com>
 <CADkLM=cZ7N+f4Bj-8MiccFcTASjBB2r1_s3BD9OFbbQOwK01cg@mail.gmail.com>
 <CACJufxE7yoH42juViFvYuCQMPwXMWxDVwiugs-BW+N4oUXB=1w@mail.gmail.com>
 <CADkLM=dFZ8-mBJDkiZZ4JadnJy8zLExUoo_b1FOs2Ozrtge=gQ@mail.gmail.com>
 <CACJufxHynx40aHHUCR4wZh1qnL=X0yw6baW4Z-+vkUgT0OhjOg@mail.gmail.com>
 <CADkLM=eCPiVhGKcbNW5bUEYpozUaKNXjd_UmBVR256p2zWtYQQ@mail.gmail.com>
 <CACJufxH4LrCpL63SRYO3zVk46YdD4--VYQoBL7GmHmCm=NCAJQ@mail.gmail.com>
 <CADkLM=cmv_bmxBe8KmZd6rEgiqSdoDfHnJa63u7rdRuAsqOwDA@mail.gmail.com>
 <CACJufxGbw9iNT8QVm4QD9cPFKnDnvDBQp7AGxkoqDa-JjzVXmg@mail.gmail.com>
 <CACJufxFkLLuX1VJ-J3fppCr37PHtxkvwyd_e4zNd+VYK0v0gnQ@mail.gmail.com>
 <5ae9578e-f25e-49c5-97ab-ad27bc2050b5@eisentraut.org>
 <CACJufxHx-UfprE6P4_ZB_cOYktHd4pLMNx=jWJFOGGGFj2YZWQ@mail.gmail.com>
In-Reply-To: 
 <CACJufxHx-UfprE6P4_ZB_cOYktHd4pLMNx=jWJFOGGGFj2YZWQ@mail.gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
Date: Fri, 27 Mar 2026 16:59:49 -0400
Message-ID: 
 <CADkLM=euzh4v-FK6Tx-yrXfZX4YVd1X5WCpWN7o5=cQsrT7-Yg@mail.gmail.com>
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User
 Functions
To: jian he <jian.universality@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Amul Sul <sulamul@gmail.com>,
	Kirill Reshke <reshkekirill@gmail.com>,
 Vik Fearing <vik@postgresfriends.org>,
	Isaac Morland <isaac.morland@gmail.com>, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d13de1064e07c8d8"
Archived-At: 
 <https://www.postgresql.org/message-id/CADkLM%3Deuzh4v-FK6Tx-yrXfZX4YVd1X5WCpWN7o5%3DcQsrT7-Yg%40mail.gmail.com>
Precedence: bulk

--000000000000d13de1064e07c8d8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 25, 2026 at 9:14=E2=80=AFAM jian he <jian.universality@gmail.co=
m> wrote:

> On Tue, Mar 24, 2026 at 9:13=E2=80=AFPM Peter Eisentraut <peter@eisentrau=
t.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?

--000000000000d13de1064e07c8d8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Mar 25, 2026 at 9:14=E2=80=AFAM jian =
he &lt;<a href=3D"mailto:jian.universality@gmail.com">jian.universality@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">On Tue, Mar 24, 2026 at 9:13=E2=80=AFPM Peter Eisentraut &lt;<a href=
=3D"mailto:peter@eisentraut.org" target=3D"_blank">peter@eisentraut.org</a>=
&gt; wrote:<br>
&gt;<br>
&gt; In patch 0012, I did not apply the changes involving<br>
&gt; float_*flow_error() in dtof().=C2=A0 These should be considered togeth=
er<br>
&gt; with the error handling changes in patch 0018 (about which below).<br>
&gt;<br>
&gt; Patch 0004 is probably ok, I just need to study a bit more, since it&#=
39;s<br>
&gt; a bit different from the other ones.<br>
&gt;<br>
&gt; In the comment for patch 0008 you write that supporting soft errors in=
<br>
&gt; int4_cash() is not easy.=C2=A0 I suppose this is because of the extern=
al<br>
&gt; function call to int8mul()?=C2=A0 Maybe that was necessary in ancient<=
br>
&gt; times, but int8mul() is nowadays just a fmgr wrapper around<br>
&gt; pg_mul_s64_overflow(), which you can call directly in int4_cash(), and=
<br>
&gt; then it should be easy.<br>
&gt;<br>
<br>
cash_numeric is not easy to refactor safely,<br>
To do this, we have to refactor (numeric_round, numeric_div), which<br>
will require refactoring more functions.<br>
So CoercionErrorSafe_Internal still checks whether the source<br>
element/base type is MONEYOID.<br></blockquote><div><br></div><div>What if =
we just...didn&#39;t? The MONEY has been deprecated since 7.4. If we simply=
 didn&#39;t implement this, and someone attempted to use this cast with def=
ault, what bad would happen?</div><div><br></div></div></div>

--000000000000d13de1064e07c8d8--