On Thursday, July 2, 2026, Robert Haas <[email protected]> wrote:
> On Wed, Jul 1, 2026 at 4:59 PM David G. Johnston > <[email protected]> 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.
