public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Haas <[email protected]>
To: Haibo Yan <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Corey Huinker <[email protected]>
Cc: jian he <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: Vik Fearing <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: implement CAST(expr AS type FORMAT 'template')
Date: Mon, 6 Jul 2026 14:18:04 -0400
Message-ID: <CA+Tgmob5JEgNO1DXVNox27dwWDpdhehd9+zdx9rHPcdOo1TG2g@mail.gmail.com> (raw)
In-Reply-To: <CABXr29G6qsR0P3x5X3xPaAZ+ENX0Tfq8+uYDTSu-iLK07_k8yQ@mail.gmail.com>
References: <CACJufxGqm7cYQ5C65Eoh1z-f+aMdhv9_7V=NoLH_p6uuyesi6A@mail.gmail.com>
<CACJufxGbsc3g6RZf0rZpKYxffK6vGkc_OsTmX54uS0kFcVBtvA@mail.gmail.com>
<CAKFQuwaG00tsXc2oSQwjdSnPQ=JuH+T8Oeejb3sO5TeqUHsfUQ@mail.gmail.com>
<CADkLM=cvhJBrCj3GV+jXfpb5+U1Z33nsvCXo-=ZkDyaSPbS-1g@mail.gmail.com>
<CAKFQuwYrwM64YnvZ5aL1DEWG50uW-1SrXesSKkmvpxXXrxTW-g@mail.gmail.com>
<[email protected]>
<CACJufxH+soqLj_AuMQj-_jxunVQKX-HBQA_3_3vmV1jTRyZ1hA@mail.gmail.com>
<CACJufxGhOOYnPtmsuVocXVNyx2gB3K68ze67CM4LUqQeW--S8g@mail.gmail.com>
<CAN4CZFNnqWbyk3UNr3XAwtKJooH8LnbDUg-f2JD9z_rG=feT7w@mail.gmail.com>
<CACJufxFVMYuVz63DteEjbMdvx2neoYcwSRb5vhO-03Tzx=B8Jw@mail.gmail.com>
<CAN4CZFNeCfLzt5g90vf_Dw5BKW2u-QhVKo369XbO-vXYq4ci5g@mail.gmail.com>
<CACJufxH4ELUjdGNi7vkHEA6L=G0SfE5abnFs5vjvEm3G-Jqsbw@mail.gmail.com>
<CADkLM=dGxwVCp3y8=LU+8hQUPw61JELx2jh02i729YCex8UqWg@mail.gmail.com>
<CA+TgmoaUzwAxa_qHSp9ybCkAhMjQRDuEAZW2BrSb1DTPiz4ZzA@mail.gmail.com>
<[email protected]>
<CABXr29G6qsR0P3x5X3xPaAZ+ENX0Tfq8+uYDTSu-iLK07_k8yQ@mail.gmail.com>
On Mon, Jul 6, 2026 at 1:14 PM Haibo Yan <[email protected]> wrote:
> The cases where I think a generic mechanism could be useful are
> broader than that. For example:
>
> text <-> date/time using datetime templates
> text <-> numeric using number templates
> text <-> bytea using hex/base64/escape
> text/bytea <-> extension types
> using external representations such as
> WKT/WKB/GeoJSON for geometry types
>
> The first two are close to the existing formatting functions. The bytea
> case is currently handled by encode()/decode(), but it has the same general
> shape: a conversion between a typed value and a textual representation,
> controlled by a format argument.
Sure, but in each case, the conversion function in question could just
be called directly.
It's also noteworthy that in each of these examples, one of the two
types is text, or maybe bytea, which, again, really makes you wonder
why this is designed as a cast-like mechanism. I guess you could have
CAST(now() to 'integer' FORMAT 'YYYY') but that seems fairly silly, so
I really don't understand why this is designed to take two arbitrary
types.
Aside from standards-compliance, the only value I can see in a feature
like this is if it's helpful to be able to name the type rather than
naming the conversion function. For instance, imagine that I could use
the same format string for conversions between a bunch of different
types. Then potentially it's handy to be able to write CAST(something
AS text FORMAT 'the string I always use') and you don't need to think
about which source type you've got at this particular call site. But
there are multiple problems with that idea. First, it seems unlikely
that the format string would be generic in that way. And second, we
already support function overloading, so you could just pick some
function name (like to_char!) and overload it to do the same thing.
Picking a function name also has the advantage of not privileging one
particular way of doing a conversion between two types over all
others, whereas this FORMAT CAST proposal requires you to decide on
one canonical method of formatting type X as type Y.
(Regular casts have this problem, too, to an extent.)
--
Robert Haas
EDB: http://www.enterprisedb.com
view thread (56+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: implement CAST(expr AS type FORMAT 'template')
In-Reply-To: <CA+Tgmob5JEgNO1DXVNox27dwWDpdhehd9+zdx9rHPcdOo1TG2g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox