Re: Macro nesting hell
| От | Tom Lane |
|---|---|
| Тема | Re: Macro nesting hell |
| Дата | |
| Msg-id | 15655.1439389092@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Macro nesting hell (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Macro nesting hell
Re: Macro nesting hell |
| Список | 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 по дате отправления: