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

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
Date: 2025-07-24 14:10:16
Message-ID: 0aa52082-152c-41d3-ac32-07818497afcd@postgresfriends.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2025-07-24 14:19:34 Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
Previous Message Robert Haas 2025-07-24 13:57:03 Re: PoC: adding CustomJoin, separate from CustomScan