From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sophie Herold <sophie_h(at)hemio(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: to_typemod(type_name) information function |
Date: | 2018-01-06 23:45:11 |
Message-ID: | 6274.1515282311@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-01-06 23:59:20 | Re: [HACKERS] plpgsql - additional extra checks |
Previous Message | Peter Geoghegan | 2018-01-06 23:40:56 | Re: [HACKERS] GUC for cleanup indexes threshold. |