Re: WIP: [[Parallel] Shared] Hash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: [[Parallel] Shared] Hash
Date: 2017-03-08 00:15:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> +++ b/src/include/storage/barrier.h
> +#include "postgres.h"

> Huh, that normally shouldn't be in a header. I see you introduced that
> in a bunch of other places too - that really doesn't look right to me.

That is absolutely not project style and is not acceptable.

The core reason why not is that postgres.h/postgres_fe.h/c.h have to be
the *first* inclusion in every compilation, for arcane portability reasons
you really don't want to know about. (Suffice it to say that on some
platforms, stdio.h isn't all that std.) Our coding rule for that is that
we put the appropriate one of these first in every .c file, while .h files
always assume that it's been included already. As soon as you break that
convention, it becomes unclear from looking at a .c file whether the
ordering requirement has been satisfied. Also, since now you've moved
the must-be-first requirement to some other header file(s), you risk
breakage when somebody applies another project convention about
alphabetizing #include references for all headers other than those magic

In short, don't even think of doing this.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2017-03-08 00:28:44 Re: delta relations in AFTER triggers
Previous Message Andres Freund 2017-03-08 00:14:07 Re: WIP: Faster Expression Processing v4