On Thursday, July 2, 2026, Robert Haas <[email protected]> wrote:
> On Thu, Jul 2, 2026 at 4:51 PM David G. Johnston > <[email protected]> wrote: > >> and the existence of a > >> format cast doesn't mean there has to be a regular cast. > > > > Disagree > > OK, but on what basis? > > If I want 'whatever'::thistype::thattype to fail and CAST(thistype AS > thattype FORMAT 'bumble') to succeed, then I need there to be a format > cast but not a regular cast 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. David J.
