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

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-01-14 22:16:12
Message-ID: CADkLM=f0xruKRH+6XvCsM1EVic9y4BL4AFo3VUfvRLdu-Qp5Gg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > + /*
> > + * Here, we cannot deparsing cast_expr directly, since
> > + * transformTypeSafeCast may have folded it into a simple
> > + * constant or NULL. Instead, we use source_expr and
> > + * default_expr to reconstruct the CAST DEFAULT clause.
> > + */
> >
> > I am wondering how other places handle expression deparsing; do they
> > hold the original expression along with the transformed expression?
>

In my initial implementation of this, I modified CoalesceExpr to ensure
that the default clause was evaluated if and only if the initial expression
failed.

> rebased, many variable names have been renamed, comments adjusted.

The new SAFE option on user defined cast functions looks good to me.

I am concerned that adding _safe overhead to all cast functions will be
received poorly, but if it is poorly received then reverting isn't that
hard.

I'm going to re-review the whole patch set, but I wanted to say that I like
the main points of the changes so far.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2026-01-14 22:17:11 Re: Patch: dumping tables data in multiple chunks in pg_dump
Previous Message Jelte Fennema-Nio 2026-01-14 22:16:04 Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta