Re: WIP: a way forward on bootstrap data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: a way forward on bootstrap data
Date
Msg-id 24009.1523987660@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: a way forward on bootstrap data  (John Naylor <jcnaylor@gmail.com>)
List pgsql-hackers
John Naylor <jcnaylor@gmail.com> writes:
> On 4/6/18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Some of the CATALOG lines spill well past 80 characters with this,
>> although many of the affected ones already were overlength, eg ...

> Thinking about this some more, a way occurred to me to shorten the
> CATALOG lines while still treating all headers the same, and with very
> little code (Patch 0001). What we do is automate the use of
> 'RelationId' and 'Relation_Rowtype_Id' so that the CATALOG macro only
> needs the part pertaining to the table name, and the BKI_ROWTYPE_OID
> macro can go back to just having the OID, eg:

Hm ... I don't like this too much, because it means that grepping for
those macros will no longer turn up the source of their definition.
Yeah, if you already know how Relation_Rowtype_Id macros are created,
you might not be confused, but I think it'd be problematic for
newcomers.  Essentially we'd be shortening these lines by obfuscating,
which doesn't seem like a good tradeoff.

It might be all right to drop the BKI_ prefixes as per your other
suggestion, but I'm worried about possible symbol conflicts.  It's
probably not really worth changing that by itself.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: reloption to prevent VACUUM from truncating empty pages at the end of relation
Next
From: Tom Lane
Date:
Subject: Re: remove quoting hacks and simplify bootscanner.l