On 2019-06-12 15:34, Tom Lane wrote:
> 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
I wrote:
> Robert Haas writes:
>> 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.
Oh, cancel that --- in an uncaffeinated moment, I thought you were asking
about spli
Robert Haas writes:
> On Wed, Jun 12, 2019 at 7:52 AM Peter Eisentraut
> 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 o
On Wed, Jun 12, 2019 at 7:52 AM Peter Eisentraut
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 r
2001
From: Peter Eisentraut
Date: Wed, 12 Jun 2019 13:17:55 +0200
Subject: [PATCH] Catalog files simplification
Extend the CATALOG() macro used in src/include/catalog/ to also create
the Form_pg_foo and FormData_pg_foo typedefs automatically.
---
src/include/catalog/genbki.h
