Re: pgsql: Fix headerscheck failure in replication/worker_internal.h

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Fix headerscheck failure in replication/worker_internal.h
Date: 2021-11-16 20:12:07
Message-ID: 2256007.1637093527@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2021-Nov-16, Stephen Frost wrote:
>> Not against possibly changing that but I don’t get the point of including
>> be-gssapi-common.h if it’s not enabled in the build and typically if GSSAPI
>> is possible and the reason for including be-gssapi-common.h then there’s
>> other things that need to be under a ifdef, again, as in auth.c

> BTW, this is exactly why my first suggestion was to add an exclusion
> rule to headerscheck so that be-gssapi-common.h is not verified by that
> script. After re-reading your response, that looks like a reasonable
> answer too.

I think adding #ifdef ENABLE_GSS as per your prior message is better.
Headers have little business making assumptions about the context in
which they're included --- which is exactly why headerscheck exists ---
so I disagree with Stephen's argument. In any case I am not in favor of
making random exclusions from that script's testing.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Stephen Frost 2021-11-16 20:16:13 Re: pgsql: Fix headerscheck failure in replication/worker_internal.h
Previous Message Stephen Frost 2021-11-16 18:57:15 Re: pgsql: Fix headerscheck failure in replication/worker_internal.h

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2021-11-16 20:16:13 Re: pgsql: Fix headerscheck failure in replication/worker_internal.h
Previous Message Mark Dilger 2021-11-16 20:08:04 Re: Non-superuser subscription owners