Re: implement CAST(expr AS type FORMAT 'template')

On Mon, Jul 6, 2026 at 4:15 PM Haibo Yan <tristan(dot)yim(at)gmail(dot)com> wrote:
> The examples I listed are mostly conversions between a typed value and a
> textual or binary representation, not arbitrary conversions between unrelated
> types. So I agree that the current pg_format_cast design may be too broad if
> it allows arbitrary source/target pairs.

Well, I don't think the issue here is really about pg_format_cast. If
the syntax supports arbitrary pairs of types, the catalog
representation should do. But there's also the question of whether we
want to support the syntax.

> Maybe the better boundary is that a formatted conversion should be between a
> data type and an external representation type, probably text or bytea.
>
> That would allow cases such as text -> date, numeric -> text, and
> bytea -> some_type, and also the existing-style text <-> bytea encoding
> case. But it should not become a generic text -> text or bytea -> bytea
> transformation mechanism, nor a second cast system for arbitrary type pairs.

But if this is in the SQL standard -- is it? -- then that ship has
already sailed. We're just left to wonder why they did it like that...

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