| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | Amul Sul <sulamul(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, 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: | 2026-03-18 03:11:18 |
| Message-ID: | CADkLM=cmv_bmxBe8KmZd6rEgiqSdoDfHnJa63u7rdRuAsqOwDA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> + if (inputElementBaseType == MONEYOID ||
> + targetElementBaseType == MONEYOID ||
> + (inputElementBaseType == CIRCLEOID &&
> + targetElementBaseType == POLYGONOID))
> + {
> + errorsafe_coercion = false;
> + }
>
What if we just reject cast functions with a non-null prosqlbody?
>
> Given the interaction with array and domain coercion, we need to think more
> about error-safe type casts for user-defined range, multirange, and
> composite
> types. For now, we should disallow error-safe casting for these types.
>
I agree. It's far better to get this working for the majority of cases, and
we can chip away at more obscure types later. There will *always* be user
defined types that we cannot account for.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Haibo Yan | 2026-03-18 03:34:40 | Re: vectorized CRC on ARM64 |
| Previous Message | Bruce Momjian | 2026-03-18 02:39:49 | Re: DOCS: typo on CLUSTER page |