MIME-Version: 1.0
References: 
 <CACJufxGqm7cYQ5C65Eoh1z-f+aMdhv9_7V=NoLH_p6uuyesi6A@mail.gmail.com>
 <4c358bf8-87e8-4760-83d5-a6f9fcd88907@postgresfriends.org>
 <CACJufxF4OW=x2rCwa+ZmcgopDwGKDXha09qTfTpCj3QSTG6Y9Q@mail.gmail.com>
 <1b702de4-86b0-4144-a2d0-38266296894f@postgresfriends.org>
 <CACJufxEH-8UPdbPoUoqNRaiOePw+s2W2DG4OpXtoSYDaW30oAg@mail.gmail.com>
 <CAKFQuwZXYxPw4wofq+zZ5D7nH0sHDBwr--qku9jWYv7dS+P8RQ@mail.gmail.com>
 <CACJufxGTeSnHn7w8r-qoQrqwCFQSC+CbiEthzpHKUd+bPr_0mA@mail.gmail.com>
 <bfcc5265-f527-4abb-9a20-75a063bc4f28@postgresfriends.org>
 <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>
 <82b4223e-84d4-432d-8167-dd698ce489f5@postgresfriends.org>
 <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>
In-Reply-To: 
 <CAKFQuwam6CKm+MJbNwFgoMJYJFuzWQ68+WqMf39ku8Q6kqtXYg@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 2 Jul 2026 18:23:43 -0400
Message-ID: 
 <CA+TgmobHaDB77i2LHRfFSDLgYiAREasv4w9wHFKNQ_0wwfdU2A@mail.gmail.com>
Subject: Re: implement CAST(expr AS type FORMAT 'template')
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Haibo Yan <tristan.yim@gmail.com>, jian he <jian.universality@gmail.com>,
	Corey Huinker <corey.huinker@gmail.com>,
 Zsolt Parragi <zsolt.parragi@percona.com>,
	Vik Fearing <vik@postgresfriends.org>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmobHaDB77i2LHRfFSDLgYiAREasv4w9wHFKNQ_0wwfdU2A%40mail.gmail.com>
Precedence: bulk

On Thu, Jul 2, 2026 at 5:52=E2=80=AFPM David G. Johnston
<david.g.johnston@gmail.com> 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 no=
t found errors.  Once a cast exists the first one could pass or fail depend=
ing 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 the=
re isn=E2=80=99t some cast pathway already available to use it.  IOW a form=
at should never be required - some default exists, like for dates today, th=
at 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 thi=
nking about the problem/design.  I=E2=80=99d rather just stick with our pol=
ymorphic to_char functions if we want some way of outputting text with a fo=
rmat 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.

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