public inbox for [email protected]  

help / color / mirror / Atom feed

From: David G. Johnston <[email protected]>
To: jian he <[email protected]>
Cc: Vik Fearing <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: implement CAST(expr AS type FORMAT 'template')
Date: Sun, 3 Aug 2025 20:36:00 -0700
Message-ID: <CAKFQuwaG00tsXc2oSQwjdSnPQ=JuH+T8Oeejb3sO5TeqUHsfUQ@mail.gmail.com> (raw)
In-Reply-To: <CACJufxGbsc3g6RZf0rZpKYxffK6vGkc_OsTmX54uS0kFcVBtvA@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>

On Sun, Aug 3, 2025 at 8:10 PM jian he <[email protected]> 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.

view thread (53+ 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]
  Subject: Re: implement CAST(expr AS type FORMAT 'template')
  In-Reply-To: <CAKFQuwaG00tsXc2oSQwjdSnPQ=JuH+T8Oeejb3sO5TeqUHsfUQ@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