Re: implement CAST(expr AS type FORMAT 'template')

On Thu, Jul 2, 2026 at 5:52 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> There is no wanting the formatless-variant to fail. There is recognition that sometime the formatless variant might fail with a syntax error and we have a way to pass a format to make the cast work.
>
> If there is no cast from thistype to thattype both will fail with cast not found errors. Once a cast exists the first one could pass or fail depending on the content being casted. If the content has an internal structure/syntax the failure mode would then be a syntax error. Overcoming a syntax error is done by specifying a format. But a format does you no good if there isn’t some cast pathway already available to use it. IOW a format should never be required - some default exists, like for dates today, that allows the non-format cast to work. We just need some way to pass in a format to that cast function if one is specified.
>
> For me the presence of the word cast in the syntax drives this way of thinking about the problem/design. I’d rather just stick with our polymorphic to_char functions if we want some way of outputting text with a format at without having to call doing so a cast.

I don't really know how to have a productive conversation about this
at this point. I agree that we might be better off just sticking with
our polymorphic to_char functions. But if we want to implement
CAST(... FORMAT ...) I do not understand how what you've written above
amounts to a coherent design proposal; it just doesn't make any sense
to me. If you spell it out with specific syntax, specific catalog
changes, and specific ways that things would work, then maybe I would
have an opinion, but right now all I can really say is that I disagree
strongly with the idea of trying to treat CAST(a AS b) and CAST(a AS b
FORMAT c) as two variants of the same thing just because they both
have CAST in the name. It matters whether they actually *do* the same
thing -- whether they could reasonably be implemented by the same code
-- and I think they can't.

--
Robert Haas
EDB: http://www.enterprisedb.com