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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Haibo Yan <tristan(dot)yim(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: implement CAST(expr AS type FORMAT 'template')
Date: 2026-07-07 12:07:14
Message-ID: CA+TgmoaPtGF27SWr9MY4jnzQtuARmikK30tS715Yj0=eB8PtHA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 6, 2026 at 11:56 PM Haibo Yan <tristan(dot)yim(at)gmail(dot)com> wrote:
> I now think my v2 patch is too broad. It tries to make CAST(... FORMAT ...)
> a generic user-defined format-cast mechanism, but SQL feature T839 is much
> narrower: formatted casts between datetime types and character strings.
>
> So I think the next version should move back closer to Jian’s original scope:
> support T839 first, rather than introduce pg_format_cast and
> CREATE FORMAT CAST. I still think we should avoid ad-hoc parser rewrites to
> specific function names, but the feature scope should be the standard
> datetime/string cases, not arbitrary source/target pairs.
>
> I also think it would be useful to retitle this thread around the standard
> feature, for example:
>
> Support SQL feature T839: formatted casts between datetime and
> character strings
>
> That seems to describe the real target better than a generic format-cast
> facility.

My current point of view is that your patch does exactly the right
thing but it's not clear whether we want it. I mean, if we eventually
want to support this feature with arbitrary types, there is no reason
not to do so from the start. Or at least, none that I can see. But
that does not address the question of whether we want the feature in
the first place, which is debatable.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-07-07 12:25:49 Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
Previous Message Álvaro Herrera 2026-07-07 11:51:51 Re: Mark class_descr strings for translation