Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions

On Mon, Jan 5, 2026 at 1:01 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:

> On Fri, Jan 2, 2026 at 2:08 PM Amul Sul <sulamul(at)gmail(dot)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.