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>
 <CADkLM=f1Jv81=s5Ckazx3zZq=M5KoBJMJkOZux_-L+gezODCEQ@mail.gmail.com>
 <CACJufxGw_OY7K3rfG4kDb902O2guhT-wgTjTJQ=pWeVWRTHpHQ@mail.gmail.com>
 <CADkLM=cFSg3+6Sk00dLAF7Q7jnrKBk6+N5gRxT5BCxRvaGtR-g@mail.gmail.com>
 <CACJufxE_aO5FtBGwhDym-Fwe7k8oJY7a8jcYDx77=t3maPvG0g@mail.gmail.com>
 <CADkLM=chahh6ddZFjLL6AUdqzL_Px0raTu-5Jzn2WN8yELtmJw@mail.gmail.com>
 <CACJufxE053=bO3pDUpGba6Yz3VGpU_XCbg4HO6Rew5EJ7k7VnQ@mail.gmail.com>
 <CACJufxF--5d=fmoRBHfqJE9Vy38dCURNKYOKKpujRCnoTEQ7nQ@mail.gmail.com>
 <CACJufxHpMJn22Nu_wmG6eV_S8SAM6KM+GhMO7GuzVb=d9q5C4A@mail.gmail.com>
 <CACJufxHM2e3DQmbRdDZvWyG3ZCLyOg6XFifvOz_TGy1tGw7NHw@mail.gmail.com>
 <CADkLM=daTLuRcwzc6Egtwvh4XYgtABWuMBVnEznd-dXqmXfzUw@mail.gmail.com>
 <CACJufxEcrrcaeFW+zYsjgb6r+ijzwszyxeHk3wxGY+3idiA2ZA@mail.gmail.com>
 <CADkLM=ehavqENDBCcYQufPFKboV90+o_uFdhcrh=Ymq_TNqo=A@mail.gmail.com>
 <CADkLM=ecTybe9Z9TSRD-NKZ=-V4DuGVRtXZGO6+F7=m3Gg9GGQ@mail.gmail.com>
 <CACJufxH5OSeY0-qirksn8S2FUycxON-O=iwc0-Nne1MTAguGhQ@mail.gmail.com>
 <CADkLM=eFasBpS1cqf67TpKGbKoUSy00FuT05Yz4RpXQBpqktuw@mail.gmail.com>
 <CACJufxHrE0s7G0xg1frWo2+tFLTLaikKCObixH-4p9zMYKtHFw@mail.gmail.com>
 <CACJufxFEzD3mqc+MDpgzvdt+4Azbn2pF6TWW=dSCqSK7OHoL6A@mail.gmail.com>
 <CALdSSPjd2fJHw8TrugumZSQwJ8VmSVn55OfQ+Wuogaq0ss=HGQ@mail.gmail.com>
 <CACJufxFzqAshLFw-xTqpz3Mu=6nMLnPiD8bBhbqX6KcFPVjEHw@mail.gmail.com>
 <CAAJ_b95nmvAYhxt2NwRAdGtvR-6STbiaFguMSLh3PmjUVE7rdg@mail.gmail.com> <CACJufxHw9Y3fvh+rZj4ukLo=v54Dpafzk7Xvee_wi9zFZ6pOfg@mail.gmail.com>
In-Reply-To: <CACJufxHw9Y3fvh+rZj4ukLo=v54Dpafzk7Xvee_wi9zFZ6pOfg@mail.gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
Date: Mon, 12 Jan 2026 11:57:37 -0500
Message-ID: <CADkLM=epcMjpRbTDm-pfzqwDrGb0U0u3o4T=_JL++AQQ9B=rZA@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: 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="00000000000071f195064833c6f4"
Archived-At: <https://www.postgresql.org/message-id/CADkLM%3DepcMjpRbTDm-pfzqwDrGb0U0u3o4T%3D_JL%2B%2BAQQ9B%3DrZA%40mail.gmail.com>
Precedence: bulk

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

On Mon, Jan 5, 2026 at 1:01=E2=80=AFAM jian he <jian.universality@gmail.com=
> wrote:

> On Fri, Jan 2, 2026 at 2:08=E2=80=AFPM Amul Sul <sulamul@gmail.com> wrote=
:
> >
> > Hi,
> >
> > I am still thinking through a design that avoids having two different
> > code paths for type casting. Can't we avoid adding a new SafeTypeCast
> > structure by simply adding a raw_default variable (name could be
> > simply default) to the existing TypeCast structure? If we do that, we
> > would need to update transformTypeCast() and other places (like
> > ExecInterpExpr()) to handle the raw_default. This approach would allow
> > us to avoid the extra code required for a new node structure (e.g.,
> > T_SafeTypeCastExpr) and a separate EEOP_SAFETYPE_CAST step.
> >
>

If that code path requires all casting operations to have the overhead of
safety, then that may be a significant performance regression and a
non-starter. I think we should continue with the design as-is, and if it
turns out later than we can merge the safe/unsafe code paths without
impacting performance, then we'll do it.

Jian, can you rebase the patch-set? I tried applying it today, without luck=
.

--00000000000071f195064833c6f4
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 Mon, Jan 5, 2026 at 1:01=E2=80=AFAM jian h=
e &lt;<a href=3D"mailto:jian.universality@gmail.com">jian.universality@gmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">On Fri, Jan 2, 2026 at 2:08=E2=80=AFPM Amul Sul &lt;<a href=3D"mailto:=
sulamul@gmail.com" target=3D"_blank">sulamul@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; I am still thinking through a design that avoids having two different<=
br>
&gt; code paths for type casting. Can&#39;t we avoid adding a new SafeTypeC=
ast<br>
&gt; structure by simply adding a raw_default variable (name could be<br>
&gt; simply default) to the existing TypeCast structure? If we do that, we<=
br>
&gt; would need to update transformTypeCast() and other places (like<br>
&gt; ExecInterpExpr()) to handle the raw_default. This approach would allow=
<br>
&gt; us to avoid the extra code required for a new node structure (e.g.,<br=
>
&gt; T_SafeTypeCastExpr) and a separate EEOP_SAFETYPE_CAST step.<br>
&gt;<br></blockquote><div><br></div><div>If that code path requires all cas=
ting operations to have the overhead=20
of safety, then that may be a significant performance regression and a=20
non-starter. I think we should continue=C2=A0with the design as-is, and if =
it turns out later than we can merge the safe/unsafe code paths without imp=
acting performance, then we&#39;ll do it.</div><div><br></div><div>Jian, ca=
n you rebase the patch-set? I tried applying it today, without luck.</div><=
/div></div>

--00000000000071f195064833c6f4--