Re: to_typemod(type_name) information function

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: to_typemod(type_name) information function
Дата
Msg-id 6274.1515282311@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: to_typemod(type_name) information function  (Sophie Herold <sophie_h@hemio.de>)
Ответы Re: to_typemod(type_name) information function
Список pgsql-hackers
Sophie Herold <sophie_h@hemio.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] GUC for cleanup indexes threshold.
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] plpgsql - additional extra checks