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>
 <CAAJ_b95rrHrY_RJqc=iJQkGrKhUUqTHGO1m3_hJ7A+aG_qxZHQ@mail.gmail.com>
 <CACJufxFjPnEv__85qfFh9c21Q7nx7dAnymcnq5tECJofTTzG7g@mail.gmail.com>
 <CAAJ_b97SC8LknASnDASqV951pBHLpxwUmE7wPQKAcWyzuDujdA@mail.gmail.com>
 <CACJufxH3LUpmeeDBgWUOxVggU4Xq6ZxVnMALE-5aT9yX0n2rYw@mail.gmail.com>
 <CAAJ_b95zduu3UU7c9YkZH3iX56SF2RWKKkRjy2dj1S4r-8272w@mail.gmail.com>
 <CACJufxHKoQxo6o3B1R1qqCaYNpntD=esj-hWL5GSCzD1K4FNtg@mail.gmail.com>
In-Reply-To: 
 <CACJufxHKoQxo6o3B1R1qqCaYNpntD=esj-hWL5GSCzD1K4FNtg@mail.gmail.com>
From: Amul Sul <sulamul@gmail.com>
Date: Thu, 4 Dec 2025 18:16:50 +0530
Message-ID: 
 <CAAJ_b94-iLFcMnW3ZHdy5NA9QprYdtsGBQcrn561b1F-A0svUw@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: Corey Huinker <corey.huinker@gmail.com>,
 Vik Fearing <vik@postgresfriends.org>,
	Isaac Morland <isaac.morland@gmail.com>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAAJ_b94-iLFcMnW3ZHdy5NA9QprYdtsGBQcrn561b1F-A0svUw%40mail.gmail.com>
Precedence: bulk

On Tue, Dec 2, 2025 at 1:23=E2=80=AFPM jian he <jian.universality@gmail.com=
> wrote:
>
> On Mon, Dec 1, 2025 at 8:09=E2=80=AFPM Amul Sul <sulamul@gmail.com> wrote=
:
> >
> > Since you declared float8_div_safe() as static inline, I believe it
> > wouldn't have any performance degradation since most compilers
> > optimize it. Also, I suggest you pass the ErrorSafeContext to
> > float_overflow_error(), float_underflow_error(), and
> > float_zero_divide_error() so that you can avoid duplicating error
> > messages.
> >
> hi.
>
> First I want to use ereturn, then I found out
> float_overflow_error, float_underflow_error, float_zero_divide_error
> used both in float4, float8.
> ereturn would not be appropriate for both types.
> so I choose errsave.
> for these 3 functions, now it looks like:

Make sense, thanks for updating the patch.

Regarding v13-0019 and v13-0020 patches, I have a bunch of comments
for the code, but I'd like to understand the implemented design first.
I have some basic questions regarding the commit message and code
comment, as follows:

"
We cannot simply prohibit user-defined functions in pg_cast for safe cast
evaluation because CREATE CAST can also utilize built-in functions. So, to
completely disallow custom casts created via CREATE CAST used in safe cast
evaluation, a new field in pg_cast would unfortunately be necessary.
"

I might not have understood the implementation completely -- can't we
use fmgr_last_builtin_oid to detect built-in functions?
--

+           /*
+            * We have to to use CoerceUnknownConstSafe rather than
+            * coerce_to_target_type. because coerce_to_target_type is not =
error
+            * safe.
+            */

How difficult would it be to modify coerce_to_target_type() to make it
error safe?

Could we utilize the existing type casting infrastructure for this, perhaps=
 by
simply considering the evolution and use of the additional default
expression? If we could, the resulting implementation would be very
clean, IMHO.

Kindly excuse and point me if that is already discussed.
--

Here are few comments for v13-0018:

 static inline void point_add_point(Point *result, Point *pt1, Point *pt2);
+static inline bool point_add_point_safe(Point *result, Point *pt1, Point *=
pt2,
+                                       Node *escontext);

+static inline float8 point_dt_safe(Point *pt1, Point *pt2, Node *escontext=
);
 static inline float8 point_sl(Point *pt1, Point *pt2);

I think we should avoid introducing the "_safe" version of static
routines in the .c file. Instead, we can add the Node *escontext
argument to the existing routines, similar to how single_decode() was
previously modified to accept it.
--

-static void poly_to_circle(CIRCLE *result, POLYGON *poly);
+static bool poly_to_circle_safe(CIRCLE *result, POLYGON *poly, Node
*escontext);

Following the previous suggestion, please keep the existing function
as it is and just add one more argument to it.
--


 }

+
 static inline float4
 float4_mi(const float4 val1, const float4 val2)
 {

A spurious change.
--

Regards,
Amul