Re: Macro nesting hell

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Macro nesting hell
Date: 2015-08-12 14:18:12
Message-ID: 15655.1439389092@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-08-12 14:42:55 Re: Macro nesting hell
Previous Message Kouhei Kaigai 2015-08-12 14:18:08 Re: Foreign join pushdown vs EvalPlanQual