On Wed, Jan 14, 2026 at 5:16 PM Corey Huinker <[email protected]> wrote:
> > + /* >> > + * 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. > I picked this back up again, pondered adding the IS CASTABLE AS syntax to the patch, but ultimately decided that it should be a separate patch. While I still think the patch order is a bit backwards [1], the order chosen does have a sense to it, and whether or not that is the right order is up to the committer. Please post a rebase so I can mark it as ready for committer. [1] I would have preferred adding the CAST functionality first, then switching over each datatype one-by-one, thus demonstrating that non-safe datatypes can co-exist with this new functionality. But that's just my personal preference.
