MIME-Version: 1.0
References: 
 <CADkLM=fv1JfY4Ufa-jcwwNbjQixNViskQ8jZu3Tz_p656i_4hQ@mail.gmail.com>
 <CAMsGm5dpfm2PHL8XZvC-JSd+UPkgx3rpReUA=G=4+rUCH+Ntcw@mail.gmail.com>
 <CADkLM=eD_S8mGhPfu5+hXXvXgR0-cxGpGd9dgPzD+nCuO7HFaQ@mail.gmail.com>
 <CACJufxHCMzrHOW=wRe8L30rMhB3sjwAv1LE928Fa7sxMu1Tx-g@mail.gmail.com>
 <04afcd1f-ed7d-4c0a-add1-50e3719ccbf9@postgresfriends.org>
 <CACJufxGRAnwJzu7nMq4ZP=yqa1Sz=qR+mR1TmY0aCDjJoJRRtg@mail.gmail.com>
 <762ae707-7fdc-43d8-a77a-3a10d12ce21d@postgresfriends.org>
 <CACJufxFy+DFpJ2e-czyCTAgSJXNFaQGWFKA4mjbW-LAMGc1YBA@mail.gmail.com>
In-Reply-To: 
 <CACJufxFy+DFpJ2e-czyCTAgSJXNFaQGWFKA4mjbW-LAMGc1YBA@mail.gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
Date: Wed, 30 Jul 2025 15:14:58 -0400
Message-ID: 
 <CADkLM=f1Jv81=s5Ckazx3zZq=M5KoBJMJkOZux_-L+gezODCEQ@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: Vik Fearing <vik@postgresfriends.org>,
 Isaac Morland <isaac.morland@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000003d101063b2a5877"
Archived-At: 
 <https://www.postgresql.org/message-id/CADkLM%3Df1Jv81%3Ds5Ckazx3zZq%3DM5KoBJMJkOZux_-L%2BgezODCEQ%40mail.gmail.com>
Precedence: bulk

--00000000000003d101063b2a5877
Content-Type: text/plain; charset="UTF-8"

>
>
> I didn't implement the [ FORMAT <cast template> ] part for now.
> please check the attached regress test and tests expected result.
>

Question about this:

+/*
+ * Push steps to evaluate a SafeTypeCastExpr and its various subsidiary
expressions.
+ * We already handle CoerceViaIO, CoerceToDomain, and ArrayCoerceExpr error
+ * softly.  However, FuncExpr (e.g., int84) cannot be made error-safe.
+ * In such cases, we wrap the source expression and target type
information into
+ * a CoerceViaIO node instead.
+ */

I'm not sure we _can_ just fall back to the CoerceViaIO if there is a
defined cast from TypeA -> TypeB. I seem to recall there was some reason we
couldn't do that, possibly to do with how it handled rounding, but I have
no clear memory of it.

Aside from that, I like what you've done with making SafeTypeCastExpr be
its own node type and not saddling regular typecasts with the overhead.

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote gmail=
_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
I didn&#39;t implement the [ FORMAT &lt;cast template&gt; ] part for now.<b=
r>
please check the attached regress test and tests expected result.<br></bloc=
kquote><div><br></div><div>Question about this:</div><div><br></div><div>+/=
*<br>+ * Push steps to evaluate a SafeTypeCastExpr and its various subsidia=
ry expressions.<br>+ * We already handle CoerceViaIO, CoerceToDomain, and A=
rrayCoerceExpr error<br>+ * softly.=C2=A0 However, FuncExpr (e.g., int84) c=
annot be made error-safe.<br>+ * In such cases, we wrap the source expressi=
on and target type information into<br>+ * a CoerceViaIO node instead.<br>+=
 */</div><div><br></div><div>I&#39;m not sure we _can_ just fall back to th=
e CoerceViaIO if there is a defined cast from TypeA -&gt; TypeB. I seem to =
recall there was some reason we couldn&#39;t do that,=C2=A0possibly to do w=
ith how it handled rounding, but I have no clear memory of it.</div><div><b=
r></div><div>Aside from that, I like what you&#39;ve done with making=C2=A0=
SafeTypeCastExpr=C2=A0be its own node type and not saddling regular typecas=
ts with the overhead.</div></div></div>

--00000000000003d101063b2a5877--