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

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

> On Wed, Jul 1, 2026 at 4:59 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > I think the fact the standard put this inside the 'cast(...)' means it's
> quite reasonable to consider the aspect part of a cast definition as
> opposed to something wholly different.
> >
> > When we issue "create table" both pg_class and pg_attribute are
> modified. It seems quite reasonable that executing "create cast" causes
> both pg_cast and pg_cast_format to be populated.
>
> I don't see how this would work. The existence of a regular cast
> doesn't mean there has to be a format cast,

Agree

>
> and the existence of a
> format cast doesn't mean there has to be a regular cast.

Disagree

> But then we'd still have to have ALTER
>
CAST commands that modify the format-cast part of the object and the
> non-format cast part of the object separately. That seems extremely
> unpleasant to sort out, especially since right now a cast can't be
> modified after it's created, and changing that might have security
> implications.

Then we don;t need the alter to be able to modify the non-format portion of
the cast. I do imagine that the formatter is an optional component of a
cast. So “alter cast … {attach|detach} formatter …”. We don’t even need a
create command component though seems nice to keep it for convenience.

I don’t have any qualms adding this so as long as fits into the existing
system cleanly. The array example does actually provide new ease-of-use
for an admittedly possibly rare use case.

David J.