| 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.
| 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 |