On Mon, Jul 6, 2026 at 4:15 PM Haibo Yan <[email protected]> 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
