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>
In-Reply-To: 
 <CACJufxH5OSeY0-qirksn8S2FUycxON-O=iwc0-Nne1MTAguGhQ@mail.gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
Date: Sun, 30 Nov 2025 23:41:37 -0600
Message-ID: 
 <CADkLM=eFasBpS1cqf67TpKGbKoUSy00FuT05Yz4RpXQBpqktuw@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="0000000000008bedfe0644dd6fec"
Archived-At: 
 <https://www.postgresql.org/message-id/CADkLM%3DeFasBpS1cqf67TpKGbKoUSy00FuT05Yz4RpXQBpqktuw%40mail.gmail.com>
Precedence: bulk

--0000000000008bedfe0644dd6fec
Content-Type: text/plain; charset="UTF-8"

>
> >> I'm fine with it. I can see having 'f' and 's' both mean cast
> functions, but 's' means safe, but the extra boolean works too and we'll be
> fine with either method.
> >
> >
> > I can work on this part if you don't have time.
>
> Do you mean change pg_cast.casterrorsafe from boolean to char?
>

No, I meant implementing the syntax for being able to declare a custom CAST
function as safe (or not). Basically adding the [SAFE] to

CREATE CAST (*source_type* AS *target_type*)
    WITH [SAFE] FUNCTION *function_name* [ (*argument_type* [, ...]) ]

I'm not tied to this syntax choice, but this one seemed the most obvious
and least invasive.

But this brings up an interesting point: if a cast is declared as WITHOUT
FUNCTION aka COERCION_METHOD_BINARY, then the cast can never fail, and we
should probably check for that because a cast that cannot fail can ignore
the DEFAULT clause altogether and fall back to being an ordinary CAST().


> Currently pg_cast.casterrorsafe works just fine.
> if the cast function is not applicable, the castfunc would be InvalidOid.
> also the cast function is either error safe or not, I don't see a
> usage case for the third value.
>

Agreed, it's fine. A committer may want a char with 's'/'u' values to keep
all the options char types, but even if they do that's a very minor change.

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

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">&gt;&gt; I&#39;m fine with it. I c=
an see having &#39;f&#39; and &#39;s&#39; both mean cast functions, but =
9;s&#39; means safe, but the extra boolean works too and we&#39;ll be fine =
with either method.<br>
&gt;<br>
&gt;<br>
&gt; I can work on this part if you don&#39;t have time.<br>
<br>
Do you mean change pg_cast.casterrorsafe from boolean to char?<br></blockqu=
ote><div><br></div><div><div>No, I meant implementing the syntax for being =
able=20
to declare a custom CAST function as safe (or not). Basically adding the
 [SAFE] to<pre class=3D"gmail-synopsis">CREATE CAST (<em class=3D"gmail-rep=
laceable"><code>source_type</code></em> AS <em class=3D"gmail-replaceable">=
<code>target_type</code></em>)
    WITH [SAFE] FUNCTION <em class=3D"gmail-replaceable"><code>function_nam=
e</code></em> [ (<em class=3D"gmail-replaceable"><code>argument_type</code>=
</em> [, ...]) ]</pre>I&#39;m not tied to this syntax choice, but this one =
seemed the most obvious and least invasive.</div><div><br></div><div>But th=
is brings up an interesting point: if a cast is declared as WITHOUT FUNCTIO=
N aka COERCION_METHOD_BINARY, then the cast can never fail, and we should p=
robably check for that because a cast that cannot fail can ignore the DEFAU=
LT clause altogether and fall back to being an ordinary CAST().</div></div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Currently pg_cast.casterrorsafe works just fine.<br>
if the cast function is not applicable, the castfunc would be InvalidOid.<b=
r>
also the cast function is either error safe or not, I don&#39;t see a<br>
usage case for the third value.<br></blockquote><br></div><div class=3D"gma=
il_quote gmail_quote_container">Agreed, it&#39;s fine. A committer may want=
 a char with &#39;s&#39;/&#39;u&#39; values to keep all the options char ty=
pes, but even if they do that&#39;s a very minor change.</div></div>

--0000000000008bedfe0644dd6fec--