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=epcMjpRbTDm-pfzqwDrGb0U0u3o4T=_JL++AQQ9B=rZA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions (jian he <jian.universality@gmail.com>) |
| Список | pgsql-hackers |
On Mon, Jan 5, 2026 at 1:01 AM jian he <jian.universality@gmail.com> wrote:
On Fri, Jan 2, 2026 at 2:08 PM Amul Sul <sulamul@gmail.com> wrote:
>
> Hi,
>
> I am still thinking through a design that avoids having two different
> code paths for type casting. Can't we avoid adding a new SafeTypeCast
> structure by simply adding a raw_default variable (name could be
> simply default) to the existing TypeCast structure? If we do that, we
> would need to update transformTypeCast() and other places (like
> ExecInterpExpr()) to handle the raw_default. This approach would allow
> us to avoid the extra code required for a new node structure (e.g.,
> T_SafeTypeCastExpr) and a separate EEOP_SAFETYPE_CAST step.
>
If that code path requires all casting operations to have the overhead of safety, then that may be a significant performance regression and a non-starter. I think we should continue with the design as-is, and if it turns out later than we can merge the safe/unsafe code paths without impacting performance, then we'll do it.
Jian, can you rebase the patch-set? I tried applying it today, without luck.
В списке pgsql-hackers по дате отправления: