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

Vik Fearing <vik@postgresfriends.org>

From: Vik Fearing <vik@postgresfriends.org>
To: jian he <jian.universality@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>, Isaac Morland <isaac.morland@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-07-24T14:10:16Z
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 →
  1. Make cast functions to type money error safe

  2. Make cast function from circle to polygon error safe

  3. Make geometry cast functions error safe

  4. Make cast functions from jsonb error safe

  5. Make many cast functions error safe

  6. Add SQL/JSON query functions

  7. Add soft error handling to some expression nodes

On 24/07/2025 03:22, jian he wrote:
> +SELECT CAST('a' as int DEFAULT sum(1) ON CONVERSION ERROR); --error
> +SELECT CAST('a' as int DEFAULT sum(1) over() ON CONVERSION ERROR); --error


This seems like an arbitrary restriction.  Can you explain why this is 
necessary?  Those same expressions are allowed as the <cast operand>.


> +SELECT CAST('a' as int DEFAULT ret_setint() ON CONVERSION ERROR) --error
> (ret_setint function is warped as (select 1 union all select 2))


This makes sense to me.


> for array coerce, which you already mentioned, i think the following
> is what we expected.
> +SELECT CAST('{234,def,567}'::text[] AS integer[] DEFAULT '{-1011}' ON
> CONVERSION ERROR);
> +  int4
> +---------
> + {-1011}
> +(1 row)


Yes, that looks correct to me.


> I didn't implement the [ FORMAT <cast template> ] part for now.


That is fine, since it's separate feature


> please check the attached regress test and tests expected result.


Except for the weird restriction on the default value, this all looks 
good to me (with the usual caveat that I am not an expert in C).


Are you planning to also implement the <castable predicate>?

-- 

Vik Fearing