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, and the existence of a format cast doesn't mean there has to be a regular cast. Expressions that use a format cast need to depend on the pg_format_cast entry, and expressions that use a regular cast need to depend on the pg_cast entry. I mean, I'm not saying something else is totally impossible. You could for example create the pg_cast entry always and make it some kind of dummy entry when there's only a format cast. Then all casts could depend on the pg_cast entry. 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. But even apart from that it doesn't seems like it will make for a very awkward user experience. I agree with Peter that I'm not really sure why we want to implement this in the first place; it doesn't seem to add any value over just having functions. The above is just a discussion about what we should do (or what I think we should do) if we do want to have it. -- Robert Haas EDB: http://www.enterprisedb.com
