On Thursday, July 2, 2026, Robert Haas <
robertmhaas@gmail.com> wrote:
On Thu, Jul 2, 2026 at 4:51 PM David G. Johnston
<david.g.johnston@gmail.com> 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.
