Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uim0A-00FegZ-Gf for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Aug 2025 03:36:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uim08-00FICL-7q for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Aug 2025 03:36:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uim07-00FICC-Pg for pgsql-hackers@lists.postgresql.org; Mon, 04 Aug 2025 03:36:39 +0000 Received: from mail-oo1-xc2d.google.com ([2607:f8b0:4864:20::c2d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uim04-000cHj-28 for pgsql-hackers@postgresql.org; Mon, 04 Aug 2025 03:36:38 +0000 Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-60402c94319so2423716eaf.1 for ; Sun, 03 Aug 2025 20:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754278596; x=1754883396; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DzSqTRp78hBhbUrcHJKTFPwvd8U80vt067cNqspbApA=; b=aX5wUl4bnbGAI8+2vWOWCjS12oBueMDwqnTp3K5pJG7JZ+AOh3odg/JQJMIYYxEZb2 gw0AbLXwchvW8LpyDYaWYlK6i4Hi1uH7lKJckFt/fmH63f44JozE90BIYFenyYXr6P8G 8I25w0YIxdo1bADJq5Nv+yZYhZoUCNSARtQQo1TF6Lxh5qvI5T+T1w2LIe6FLb3ivYO+ JhuqBV+vR+HpG7PN05VSGAdSdk+aKvLlnpbrkL0M42esKFgfaz8vd0a70JxgBt7CSnrw tb0BKV99E/jd7Su15hA9/nUqtXhTrCmhoI4sO9U2M2P0WeOgMOrk1eCBqZckI24LvVNl X+6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754278596; x=1754883396; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DzSqTRp78hBhbUrcHJKTFPwvd8U80vt067cNqspbApA=; b=BSjA7o3m9EGoW/x1FivB/EQc9ndUG0c9EuRtZ40UGQuvvdB+yS8pVHobpjeSPDAaqM ItpNHTWL6ni9Ll/dYwt7eCMCv3X9oLBtW0EscWgeMjgcLwmk5thB/mQjwuvIzIa3n4DL hbwaIKefgNN/1mEyfmKA1zqB8yNJmj5x+4fvjPDSZfiO/8mbmDprioQpIQ1LMsdOUljK 42VhYOafuuUhF6fE51CW74eCHaF9ZcZnzbJdoL2UbHdo5rCaG3Cr6G3Ji1qXsA09UagD HVTmY/vrapV8ABzYVZlajibH+QsEU66Z8Aewg/nDDgOzKXDiYq7y2IBFGozDQ/qFuDyy I9Sw== X-Forwarded-Encrypted: i=1; AJvYcCUhFXKusxrqVeeNfHRipTUhozbMJLDOhP/ZzIL4e2fyLLoPCSc6/6uWQZ7Qn/rCVIvwXD927VtLWVamuRXk@postgresql.org X-Gm-Message-State: AOJu0YyQN5sXwj5hndPVvvuhRUdnpEkwLDAj7rTspDBgWhz2WbN8SP4D 2XDG+aSV45aDxyJ3h9qgs34+StNmHNqYbcBXWjbKzq+27qujvNaLIaspk3rTV1mMletnyub6ZDK 7hBu+5IIdTjA0U+rOn4wGrYxTlTc5xzI= X-Gm-Gg: ASbGnctwlman/CYW+WW39LfnMNCioEO/ywnaxxxmymEVjjNLdUedvBYpys839/3fk01 qO7nA3xEamZAwxzF8WW+1RVLUENwr5inuEvsAcqRJ8MfoePMBeQ8pV/UhCgcUSapnC99VmDyEmY Bj5sowBBzA5MmQsmjy2c2E40NhBHvLb4nyGLUXDNBAV1uOvtnsKsD0xzQgkDIHVVBCMUj95RnV1 AM7HGw+GYMS83Sw6TfND29v/xaDtiElxFA0RptG X-Google-Smtp-Source: AGHT+IG59os39L8yx9odhfGu43+DpU97UWNmbr26B8HqL3qu9BYISO7ms8dicfw5bJn3FbQ7WvbOOCe6k19HutH4zNc= X-Received: by 2002:a05:6820:8185:b0:619:5ed4:b198 with SMTP id 006d021491bc7-6198f24d107mr3957934eaf.5.1754278596210; Sun, 03 Aug 2025 20:36:36 -0700 (PDT) MIME-Version: 1.0 References: <4c358bf8-87e8-4760-83d5-a6f9fcd88907@postgresfriends.org> <1b702de4-86b0-4144-a2d0-38266296894f@postgresfriends.org> In-Reply-To: From: "David G. Johnston" Date: Sun, 3 Aug 2025 20:36:00 -0700 X-Gm-Features: Ac12FXxNMUuC4iJKZ9aNJYzpcJZes5UKZE28ioQi0krZ2EmFJxjl8Uh2Ne_DOg4 Message-ID: Subject: Re: implement CAST(expr AS type FORMAT 'template') To: jian he Cc: Vik Fearing , PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000908abe063b81d068" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000908abe063b81d068 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 3, 2025 at 8:10=E2=80=AFPM jian he wrote: > hi. > one more question: > > For binary coercible type casts, no formatted related function for it, > should we error out? > For example, should the following error out or return text '1'. > > select cast('1'::text as text format 'YYYY'::text); > I'm hoping the standard says (or allows us to) error out here. text as a type has no semantics on which to associate a format so it should be an error to attempt to do so. Not a silent no-op. I was under the impression that for format to be allowed in the expression one of the two data types involved has to be text and the other must not be text. IME we are actually implementing a formatting option for text serialization and deserialization here, not a cast (we are just borrowing existing syntax that is serviceable). Hence the absence of these entries in pg_cast and why the fit into pg_type seems so reasonable. The existence of the various "to_char" and "to_date" functions reflects the historical lack of a dedicated syntax for this kind of (de-)serialization. But it seems unwise to bias ourselves to how the new syntax/feature should be implemented just because these functions exist. At least one design should be done pretending they don't and see what comes out of it. Their code can always be moved or reused in whatever we come up with; forcing them to be used directly, as-is, within the new solution adds an unnecessary constraint. David J. --000000000000908abe063b81d068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 3, 2025 at 8:10=E2=80=AFPM jian he <jian.universality@gmail.com>= wrote:
=
hi.
one more question:

For binary coercible type casts, no formatted related function for it,
should we error out?
For example, should the following error out or return text '1'.

select cast('1'::text as text format 'YYYY'::text);

I'm hoping the standard says (or allows us t= o) error out here.

text as a type has no semantics on = which to associate a format so it should=C2=A0be an error to attempt to do = so.=C2=A0 Not a silent no-op.

I was under the impressi= on that for format to be allowed in the expression one of the two data type= s involved has to be text and the other must not be text.

IME we are actually implementing a formatting option for text seriali= zation and deserialization here, not a cast (we are just borrowing existing= syntax that=C2=A0is serviceable).=C2=A0 Hence the absence of these entries= in pg_cast and why the fit into pg_type seems so reasonable.

<= /div>
The existence of the various "to_char" and "to_date&= quot; functions reflects the historical lack of a dedicated syntax for this= kind of (de-)serialization.=C2=A0 But it seems unwise to bias ourselves to= how the=C2=A0new syntax/feature should be implemented just because these f= unctions exist.=C2=A0 At least one design should be done pretending they do= n't and see what comes out of=C2=A0it.=C2=A0 Their code can always be m= oved or reused in whatever we come up with; forcing them to be used directl= y, as-is, within the new solution adds an unnecessary constraint.
<= br>
David J.

--000000000000908abe063b81d068--