Re: catalog files simplification

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: catalog files simplification
Дата
Msg-id 24267.1560346479@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: catalog files simplification  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: catalog files simplification  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: catalog files simplification  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 12, 2019 at 7:52 AM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> The current catalog files all do this:
>> 
>> CATALOG(pg_aggregate,2600,AggregateRelationId)
>> {
>> ...
>> } FormData_pg_aggregate;
>> 
>> typedef FormData_pg_aggregate *Form_pg_aggregate;
>> 
>> The bottom part of this seems redundant.  With the attached patch, we
>> can generate that automatically, so this becomes just
>> 
>> CATALOG(pg_aggregate,2600,AggregateRelationId)
>> {
>> ...
>> };

> Maybe the macro definition could be split across several lines instead
> of having one really long line?

I think that would complicate Catalog.pm; not clear if it's worth it.

> Are some compilers going to be sad about typedef struct x x; preceding
> any declaration or definition of struct x?

Nope, we have lots of instances of that already, cf "opaque struct"
declarations in various headers.

A bigger objection might be that this would leave us with no obvious-
to-the-untrained-eye declaration point for either the struct name or
the two typedef names.  That might make tools like ctags sad.  Perhaps
it's not really any worse than today, but it bears investigation.

We should also check whether pgindent has any issue with this layout.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: catalog files simplification
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Are there still non-ELF BSD systems?