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

On Thursday, July 2, 2026, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Jul 2, 2026 at 4:51 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)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.