Re: implement CAST(expr AS type FORMAT 'template')
От | jian he |
---|---|
Тема | Re: implement CAST(expr AS type FORMAT 'template') |
Дата | |
Msg-id | CACJufxGTeSnHn7w8r-qoQrqwCFQSC+CbiEthzpHKUd+bPr_0mA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: implement CAST(expr AS type FORMAT 'template') ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: implement CAST(expr AS type FORMAT 'template')
|
Список | pgsql-hackers |
On Tue, Jul 29, 2025 at 11:54 AM David G. Johnston <david.g.johnston@gmail.com> wrote: > > The slight variation to this would be to specify these 2/4 and 1-arg functions as optional “format_in” and “format_out”optional properties (like typmod_in). The format-aware code can look for these which will end up having thefull implementation while the current IO functions would simply stub out calls, passing null as the format. (Or maybesome variation that looks similar to typmod handling…which I haven’t looked at.) > This may also work. typmod_in, typmod_out, which is associated with typmod, which is used in many places. The only use case for (typformatin, typformatout) is CAST expression. so we also need to consider the overhead of adding two oid columns (typformatin, typformatout) to pg_type. another question is: should we first implement CAST(expr AS type FORMAT 'template') for limited types (to_date, to_char, to_number, to_timestamptz) or first try to make it more generic?
В списке pgsql-hackers по дате отправления: