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