From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: implement CAST(expr AS type FORMAT 'template') |
Date: | 2025-07-28 10:47:47 |
Message-ID: | 1b702de4-86b0-4144-a2d0-38266296894f@postgresfriends.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28/07/2025 10:41, jian he wrote:
> select oid, castsource::regtype, casttarget::regtype,
> castfunc::regproc, castcontext, castmethod
> from pg_cast
> where casttarget::regtype::text in ('text') or
> castsource::regtype::text in ('text');
>
> As you can see from the query output, cast from other type to text or
> cast from text to other type is not in the pg_cast catalog entry.
> there are in type input/output functions. it will be represented as a
> CoerceViaIO node.
> see function find_coercion_pathway (src/backend/parser/parse_coerce.c
> line:3577).
This is the same issue I came across when I tried to implement it
several years ago.
> adding these pg_cast entries seems tricky.
> for example:
> (assume castsource as numeric, casttarget as text)
> will
> (castsource as numeric, casttarget as text, castfunc as numeric_out,
> castformatfunc as numeric_to_char)
> ever work?
> but numeric_out' result type is cstring.
I had been imagining another castcontext that would only specify the
castfunc when the FORMAT claused is used, otherwise the current method
of passing through IO would be used.
> so I tend to think adding castformatfunc to pg_cast will not work.
Perhaps not, but we need to find a way to make this generic so that
custom types can define formatting rules for themselves.
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Wienhold | 2025-07-28 10:49:02 | Re: Regression with large XML data input |
Previous Message | Jehan-Guillaume de Rorthais | 2025-07-28 10:32:35 | Re: restore_command return code behaviour |