| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | jian he <jian(dot)universality(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-01 05:41:37 |
| Message-ID: | CADkLM=eFasBpS1cqf67TpKGbKoUSy00FuT05Yz4RpXQBpqktuw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> >> 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.
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().
> Currently pg_cast.casterrorsafe works just fine.
> if the cast function is not applicable, the castfunc would be InvalidOid.
> also the cast function is either error safe or not, I don't see a
> usage case for the third value.
>
Agreed, it's fine. A committer may want a char with 's'/'u' values to keep
all the options char types, but even if they do that's a very minor change.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2025-12-01 05:50:07 | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
| Previous Message | Soumya S Murali | 2025-12-01 05:35:19 | Re: [PATCH] Expose checkpoint timestamp and duration in pg_stat_checkpointer |