|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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
|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|