On Thu, Jul 2, 2026 at 5:52 PM David G. Johnston <[email protected]> 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
