Re: pgsql: Fix headerscheck failure in replication/worker_internal.h - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pgsql: Fix headerscheck failure in replication/worker_internal.h
Date
Msg-id CAOuzzgohQerBnqgwyuAEos6O5-oAxSR_natTjr2=wuSn-ewmEg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Fix headerscheck failure in replication/worker_internal.h  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greetings,

On Tue, Nov 16, 2021 at 15:12 Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@alvh.no-ip.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.

I don’t feel all that strongly either way, so if you’d rather have it that way then that’s fine.  Will still need the other ifdefs too anyway though, but I guess it isn’t that big of a deal. 

Thanks,

Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Fix headerscheck failure in replication/worker_internal.h
Next
From: Robert Haas
Date:
Subject: Re: RecoveryInProgress() has critical side effects