Re: generating bootstrap entries for array types

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: generating bootstrap entries for array types
Дата
Msg-id 15535.1537459852@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: generating bootstrap entries for array types  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Ответы Re: generating bootstrap entries for array types  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Список pgsql-hackers
ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>> Doing this in genbki.pl makes DBD::Pg lose its array type information,
>> since it uses Catalog::ParseData() to get it
>> (https://github.com/bucardo/dbdpg/blob/master/types.c#L439).  May I
>> suggest moving gen_array_types() to Catalog.pm and calling it from
>> ParseData() if the input file is pg_type.dat, so that it always returns
>> complete data?

> Attached is a proposed revision of this patch that does the above.  It
> passes check-world, reformat_dat_file.pl still works, and DBD::Pg is
> still able to get the array type information.

I find the way you did that (making the call dependent on
$preserve_formatting) to be a mighty ugly kluge.  It causes ParseData
to know far more than it should about what callers are likely to do with
the data.

I'm inclined to think the right way is to do the expansion always,
and teach reformat_dat_file.pl to drop autogenerated array types
on the way out, making this work more like the existing facilities
for default/computed fields.

The easiest way to make that happen seems to be to invent another, purely
internal metadata field, along the lines of "is_autogenerated_entry".
Fooling with that now ...

            regards, tom lane


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

Предыдущее
От: Dave Cramer
Дата:
Сообщение: v11 transaction semantics inside procedures
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: v11 transaction semantics inside procedures