Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
| От | Corey Huinker |
|---|---|
| Тема | Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions |
| Дата | |
| Msg-id | CADkLM=eFasBpS1cqf67TpKGbKoUSy00FuT05Yz4RpXQBpqktuw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions (jian he <jian.universality@gmail.com>) |
| Список | 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 (I'm not tied to this syntax choice, but this one seemed the most obvious and least invasive.source_typeAStarget_type) WITH [SAFE] FUNCTIONfunction_name[ (argument_type[, ...]) ]
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.
В списке pgsql-hackers по дате отправления: