On Thu, Jul 2, 2026 at 11:13 PM Peter Eisentraut <[email protected]> wrote: > > On 18.06.26 16:51, Robert Haas wrote: > > The reason I somewhat hesitate to endorse that specific proposal is > > that I'm not convinced that we should actually treat this as a form of > > casting. Casts can be set to IMPLICIT or ASSIGNMENT or EXPLICIT, and > > they can be WITHOUT FUNCTION or WITH INOUT, and none of that can be > > relevant here. A CAST with FORMAT always needs to be implemented by a > > function, is always explicit from a syntax point of view, and the code > > to implement probably looks pretty different from the code needed for > > a non-FORMAT cast. I am somewhat inclined to think we want something > > that's like a cast function but actually a wholly separate mechanism, > > e.g. a new pg_formatter catalog. I note that Jian He proposed putting > > something in pg_type but I don't see how that can work, since there > > are two types involved. > > > > I don't accept the argument that we should start with this and extend > > it later. The patch as proposed is just syntactic sugar. Said another > > way, there is existing syntax that already delivers the functionality. > > So I don't see why we would rush out support for a bit of new syntax; > > anyone who wants to use this functionality can already do so. Getting > > the infrastructure right is, IMHO, the interesting part of the > > project, and I think that work needs to be done first. > > I don't really understand the purpose of this feature to begin with. > You can already call the formatting functions directly. Does this cast > syntax offer anything on top of that? >
https://www.postgresql.org/message-id/762ae707-7fdc-43d8-a77a-3a10d12ce21d%40postgresfriends.org After this implemented, we can begin fully supporting: <cast specification> ::= CAST <left paren> <cast operand> AS <cast target> [ FORMAT <cast template> ] [ <cast error behavior> ON CONVERSION ERROR ] <right paren>
