| From: | jian he <jian(dot)universality(at)gmail(dot)com> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, 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-12-09 03:39:11 |
| Message-ID: | CACJufxHrE0s7G0xg1frWo2+tFLTLaikKCObixH-4p9zMYKtHFw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 1, 2025 at 1:41 PM Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>>
>> >> I'm fine with it. I can see having 'f' and 's' both mean cast functions, but 's' means safe, but the extra boolean works too and we'll be fine with either method.
>> >
>> >
>> > I can work on this part if you don't have time.
>>
>> Do you mean change pg_cast.casterrorsafe from boolean to char?
>
>
> No, I meant implementing the syntax for being able to declare a custom CAST function as safe (or not). Basically adding the [SAFE] to
>
> CREATE CAST (source_type AS target_type)
> WITH [SAFE] FUNCTION function_name [ (argument_type [, ...]) ]
>
> I'm not tied to this syntax choice, but this one seemed the most obvious and least invasive.
>
hi.
In v14, I have removed pg_cast.casterrorsafe, but for user-defined CREATE CAST,
castfunc can be built-in function or user-defined function, we do need a way to
distinguish if the cast function is error safe or not.
I’ll incorporate pg_cast.casterrorsafe along with the implementation of the
user-defined CREATE CAST syntax into one patch.
> But this brings up an interesting point: if a cast is declared as WITHOUT FUNCTION aka COERCION_METHOD_BINARY, then the cast can never fail, and we should probably check for that because a cast that cannot fail can ignore the DEFAULT clause altogether and fall back to being an ordinary CAST().
>
>>
integer and oid are binary coercible, but the following should fail.
SELECT CAST(11 as oid DEFAULT 'a' ON CONVERSION ERROR);
if you mean that skip
+ ExecInitExprRec((Expr *) stcstate->stcexpr->default_expr,
+ state, resv, resnull);
For binary-coercible types, this approach seems fine. We’ve done something
similar in ExecInitExprRec for T_ArrayCoerceExpr.
```
if (elemstate->steps_len == 1 &&
elemstate->steps[0].opcode == EEOP_CASE_TESTVAL)
{
/* Trivial, so we need no per-element work at runtime */
elemstate = NULL;
}
```
in V14, I didn't do this part, I'll keep this in mind.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2025-12-09 03:47:08 | Re: Trying out read streams in pgvector (an extension) |
| Previous Message | Chao Li | 2025-12-09 03:38:53 | Re: [Proposal] Adding callback support for custom statistics kinds |