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
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 |