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

On Wed, Mar 11, 2026 at 12:22 AM Corey Huinker <corey.huinker@gmail.com> wrote:
>
> While I still think the patch order is a bit backwards [1], the order chosen does have a sense to it, and whether or
notthat 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
demonstratingthat non-safe datatypes can co-exist with this new functionality. But that's just my personal preference. 

We can evaluate CoerceViaIO in an error-safe manner in the HEAD.
However, as discussed in this thread[1], we cannot simply take a FuncExpr
produced by a TYPE CAST, convert it to a CoerceViaIO node, and rely on
CoerceViaIO to do the actual soft-error evaluation.
Therefore to support the CAST(expr AS newtype DEFAULT expr ON CONVERSION ERROR)
syntax, refactoring the existing cast functions to make them error-safe is
really necessary.
Overall I think refactoring the existing cast function (replacing
ereport to ereturn or errsave) should be done first.

I did one more round of comment refactoring and variable renaming.

[1]: https://www.postgresql.org/message-id/CACJufxGw_OY7K3rfG4kDb902O2guhT-wgTjTJQ%3DpWeVWRTHpHQ%40mail.gmail.com


--
jian
https://www.enterprisedb.com/