Re: Macro nesting hell - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Macro nesting hell
Date
Msg-id 15655.1439389092@sss.pgh.pa.us
Whole thread Raw
In response to Re: Macro nesting hell  (Andres Freund <andres@anarazel.de>)
Responses Re: Macro nesting hell  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Macro nesting hell  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2015-07-01 12:55:48 -0300, Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> I'm thinking we really ought to mount a campaign to replace some of these
>>> macros with inlined-if-possible functions.

>> My guess is that changing a very small amount of them will do a large
>> enough portion of the job.

> I think it'd be good to convert the macros in bufpage.h and bufmgr.h
> that either currently have multiple evaluation hazards, or have a
> AssertMacro() in them. The former for obvious reasons, the latter
> because that immediately makes them rather large (on and it implies
> multiple evaluation hazards anyway).

> That'd mean inlining PageSetPageSizeAndVersion(), PageGetSpecialSize(),
> PageGetSpecialPointer(), PageGetItem(), PageGetMaxOffsetNumber(),
> PageIsPrunable(), PageSetPrunable(), PageClearPrunable(),
> BufferIsValid(), BufferGetBlock(), BufferGetPageSize().

Sounds reasonable to me.  If you do this, I'll see whether pademelon
can be adjusted to build using the minimum macro expansion buffer
size specified by the C standard.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Tab completion for CREATE SEQUENCE
Next
From: Kouhei Kaigai
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual