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

On Mon, Nov 10, 2025 at 11:36 PM Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
wrote:

> As mentioned before, to make
>> CAST(source_expr AS target_type DEFAULT expr ON CONVERSION ERROR);
>> work,
>> we cannot just simply replace casting FuncExpr nodes with CoerceViaIO,
>> since
>> type modifiers behave differently in these two Nodes.
>> (e.g., casting numeric 1.11 to integer is not equivalent to casting the
>> literal
>> "1.11" to integer).
>>
>
> I wasn't suggesting that. I was suggesting that we move tests that use a
> given type's custom cast function into the same patch that makes that cast
> safe. This would mean that the initial syntax+nodes+executor patch starts
> out only with test cases known to not have custom functions.
>

With a second look at the patches, I think the organization is fine as-is.

>> Also, are we settled on this new pg_cast column name
>> (pg_cast.casterrorsafe)?
>> Overall, I think it's better not to touch pg_cast.dat in each of these
>> refactoring patches.
>>
>
> 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.

> I'll get to reviewing this patchset soon.
>

Not as soon as I would have liked, but the patchset still applies without
error, and survives all of my attempts to break it, including user defined
functions that generate errors deterministically as well as
non-deterministically, hoping to see it incorrectly use the default rather
than reporting the error.