| 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-11-25 12:27:52 |
| Message-ID: | CACJufxH5OSeY0-qirksn8S2FUycxON-O=iwc0-Nne1MTAguGhQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 21, 2025 at 3:32 PM Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>
>>>
>>> Also, are we settled on this new pg_cast column name (pg_cast.casterrorsafe)?
>>> Overall, I think it's better not to touch pg_cast.dat in each of these
>>> refactoring patches.
>>
>>
>> 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?
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.
attached v12-0004 fixes the xmlparse error, see
https://cirrus-ci.com/task/6181359384788992?logs=build#L1217.
all other patches remain the same as v11.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2025-11-25 12:36:52 | Re: Partial hash index is not used for implied qual. |
| Previous Message | Tender Wang | 2025-11-25 12:07:17 | Re: Some optimizations for COALESCE expressions during constant folding |