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

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, 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