From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sophie Herold <sophie_h(at)hemio(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: to_typemod(type_name) information function |
Date: | 2018-03-01 10:16:55 |
Message-ID: | 20180301101655.z45jkif6t44zu2sk@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-01-06 18:45:11 -0500, Tom Lane wrote:
> Sophie Herold <sophie_h(at)hemio(dot)de> writes:
> > the following patch allows to retrieve the typemod. Without this patch,
> > it does not seem to be possible to generate the first column.
>
> I thought about this a bit, and I now follow the problem you want to
> solve, and agree that format_type() is going in the wrong direction.
> However, the proposed solution seems a bit grotty. You're basically
> always going to need to run parseTypeString twice on the same input,
> because there are few if any use-cases for getting just the typmod
> without the type OID. I think it might be more useful to provide
> a single function
>
> parse_type(type_name text, OUT typeid regtype, OUT typmod integer)
>
> which would replace both to_regtype and to_typemod in your example.
> Usage might look like
>
> SELECT format_type(typeid, typmod)
> FROM (VALUES
> ('INTERVAL SECOND (5)'),
> ('Varchar(17)'),
> ('timestamptz (2)')) AS x(t), parse_type(x.t);
>
> Creating a function with multiple OUT parameters at the pg_proc.h level
> is slightly painful, but see e.g. pg_sequence_parameters for a model.
As there's been no activity on this thread since this comment I'm
marking this returned with feedback. Sophie, are you planning to
implement something along these lines?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Glukhov | 2018-03-01 10:20:29 | Re: Cast jsonb to numeric, int, float, bool |
Previous Message | Rushabh Lathia | 2018-03-01 10:16:12 | change in behaviour for format_type() call |