Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions

On Wed, Jan 14, 2026 at 5:16 PM Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
wrote:

> > + /*
>> > + * Here, we cannot deparsing cast_expr directly, since
>> > + * transformTypeSafeCast may have folded it into a
>> simple
>> > + * constant or NULL. Instead, we use source_expr and
>> > + * default_expr to reconstruct the CAST DEFAULT clause.
>> > + */
>> >
>> > I am wondering how other places handle expression deparsing; do they
>> > hold the original expression along with the transformed expression?
>>
>
> In my initial implementation of this, I modified CoalesceExpr to ensure
> that the default clause was evaluated if and only if the initial expression
> failed.
>
>
>
>> rebased, many variable names have been renamed, comments adjusted.
>
>
> The new SAFE option on user defined cast functions looks good to me.
>
> I am concerned that adding _safe overhead to all cast functions will be
> received poorly, but if it is poorly received then reverting isn't that
> hard.
>
> I'm going to re-review the whole patch set, but I wanted to say that I
> like the main points of the changes so far.
>

I picked this back up again, pondered adding the IS CASTABLE AS syntax to
the patch, but ultimately decided that it should be a separate patch.

While I still think the patch order is a bit backwards [1], the order
chosen does have a sense to it, and whether or not that is the right order
is up to the committer. Please post a rebase so I can mark it as ready for
committer.

[1] I would have preferred adding the CAST functionality first, then
switching over each datatype one-by-one, thus demonstrating that non-safe
datatypes can co-exist with this new functionality. But that's just my
personal preference.