public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Haas <[email protected]>
To: David G. Johnston <[email protected]>
Cc: Haibo Yan <[email protected]>
Cc: jian he <[email protected]>
Cc: Corey Huinker <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: Vik Fearing <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: implement CAST(expr AS type FORMAT 'template')
Date: Thu, 2 Jul 2026 18:23:43 -0400
Message-ID: <CA+TgmobHaDB77i2LHRfFSDLgYiAREasv4w9wHFKNQ_0wwfdU2A@mail.gmail.com> (raw)
In-Reply-To: <CAKFQuwam6CKm+MJbNwFgoMJYJFuzWQ68+WqMf39ku8Q6kqtXYg@mail.gmail.com>
References: <CACJufxGqm7cYQ5C65Eoh1z-f+aMdhv9_7V=NoLH_p6uuyesi6A@mail.gmail.com>
<[email protected]>
<CACJufxF4OW=x2rCwa+ZmcgopDwGKDXha09qTfTpCj3QSTG6Y9Q@mail.gmail.com>
<[email protected]>
<CACJufxEH-8UPdbPoUoqNRaiOePw+s2W2DG4OpXtoSYDaW30oAg@mail.gmail.com>
<CAKFQuwZXYxPw4wofq+zZ5D7nH0sHDBwr--qku9jWYv7dS+P8RQ@mail.gmail.com>
<CACJufxGTeSnHn7w8r-qoQrqwCFQSC+CbiEthzpHKUd+bPr_0mA@mail.gmail.com>
<[email protected]>
<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>
<CABXr29FyPC7terFF7E+r462BEHhYgv06oUVoBrhkH7xhshuE6A@mail.gmail.com>
<CA+TgmoYW4_Ze_iT-o64VuFGqpm48hh=4dyZJwqiWfRPDTW+L+g@mail.gmail.com>
<CABXr29HF+AHV0FNxQfHyN-ByW6-3+pTBe5Pxm23wRpBYOmfohA@mail.gmail.com>
<CACJufxFM1cq+wj8ydmsPAYEh63g5rP2tdn+y3QOUrhaA1a+Sgg@mail.gmail.com>
<CABXr29FJ94+DNwktmCjt=WNLmYzUAUREqr-P01CuiUksC8Y0SA@mail.gmail.com>
<CAKFQuwbOgm=-Q-J1pRR30Xcg-RcCmSOJ5RFduoQgHNZ08OvxnQ@mail.gmail.com>
<CA+TgmoaWpZyokE-Dj=qRyPRMLRv73C4eVvFm31wq6f-ifW_c-A@mail.gmail.com>
<CAKFQuwaiQA0JL7G7c5nk0H64pgCvWDrTL-pd++E24QPNQHQfPg@mail.gmail.com>
<CA+TgmobibgO2a3UDr7DrbKVnDG9ZViYTn6+nKR3Kq88Aii7-fw@mail.gmail.com>
<CAKFQuwam6CKm+MJbNwFgoMJYJFuzWQ68+WqMf39ku8Q6kqtXYg@mail.gmail.com>
On Thu, Jul 2, 2026 at 5:52 PM David G. Johnston
<[email protected]> wrote:
> There is no wanting the formatless-variant to fail. There is recognition that sometime the formatless variant might fail with a syntax error and we have a way to pass a format to make the cast work.
>
> If there is no cast from thistype to thattype both will fail with cast not found errors. Once a cast exists the first one could pass or fail depending on the content being casted. If the content has an internal structure/syntax the failure mode would then be a syntax error. Overcoming a syntax error is done by specifying a format. But a format does you no good if there isn’t some cast pathway already available to use it. IOW a format should never be required - some default exists, like for dates today, that allows the non-format cast to work. We just need some way to pass in a format to that cast function if one is specified.
>
> For me the presence of the word cast in the syntax drives this way of thinking about the problem/design. I’d rather just stick with our polymorphic to_char functions if we want some way of outputting text with a format at without having to call doing so a cast.
I don't really know how to have a productive conversation about this
at this point. I agree that we might be better off just sticking with
our polymorphic to_char functions. But if we want to implement
CAST(... FORMAT ...) I do not understand how what you've written above
amounts to a coherent design proposal; it just doesn't make any sense
to me. If you spell it out with specific syntax, specific catalog
changes, and specific ways that things would work, then maybe I would
have an opinion, but right now all I can really say is that I disagree
strongly with the idea of trying to treat CAST(a AS b) and CAST(a AS b
FORMAT c) as two variants of the same thing just because they both
have CAST in the name. It matters whether they actually *do* the same
thing -- whether they could reasonably be implemented by the same code
-- and I think they can't.
--
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]
Subject: Re: implement CAST(expr AS type FORMAT 'template')
In-Reply-To: <CA+TgmobHaDB77i2LHRfFSDLgYiAREasv4w9wHFKNQ_0wwfdU2A@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