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

Corey Huinker <corey.huinker@gmail.com>

From: Corey Huinker <corey.huinker@gmail.com>

To: jian he <jian.universality@gmail.com>

Cc: Vik Fearing <vik@postgresfriends.org>, Isaac Morland <isaac.morland@gmail.com>, pgsql-hackers@lists.postgresql.org

Date: 2025-07-30T19:14:58Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Make cast functions to type money error safe
- b36b95640487 19 (unreleased) landed
Make cast function from circle to polygon error safe
- 26f9012beecf 19 (unreleased) landed
Make geometry cast functions error safe
- 45cdaf3665be 19 (unreleased) landed
Make cast functions from jsonb error safe
- 10e4d8aaf46f 19 (unreleased) landed
Make many cast functions error safe
- e2f289e5b9b8 19 (unreleased) landed
Add SQL/JSON query functions
- 6185c9737cf4 17.0 cited
Add soft error handling to some expression nodes
- aaaf9449ec6b 17.0 cited

>
>
> I didn't implement the [ FORMAT <cast template> ] part for now.
> please check the attached regress test and tests expected result.
>

Question about this:

+/*
+ * Push steps to evaluate a SafeTypeCastExpr and its various subsidiary
expressions.
+ * We already handle CoerceViaIO, CoerceToDomain, and ArrayCoerceExpr error
+ * softly.  However, FuncExpr (e.g., int84) cannot be made error-safe.
+ * In such cases, we wrap the source expression and target type
information into
+ * a CoerceViaIO node instead.
+ */

I'm not sure we _can_ just fall back to the CoerceViaIO if there is a
defined cast from TypeA -> TypeB. I seem to recall there was some reason we
couldn't do that, possibly to do with how it handled rounding, but I have
no clear memory of it.

Aside from that, I like what you've done with making SafeTypeCastExpr be
its own node type and not saddling regular typecasts with the overhead.