Re: libpq-fe.h should compile *entirely* standalone

2023-03-04 Thread Tom Lane
Andrew Dunstan writes: > On 2023-03-03 Fr 13:46, Tom Lane wrote: >> This is actually moving the inclusion-check goalposts quite far, >> but HEAD seems to pass cleanly, and again we can always adjust later. >> Any objections? > LGTM Pushed, thanks for looking. regards,

Re: libpq-fe.h should compile *entirely* standalone

2023-03-04 Thread Andrew Dunstan
On 2023-03-03 Fr 13:46, Tom Lane wrote: I wrote: We can easily do better, as attached, but I wonder which other headers should get the same treatment. After a bit of further research I propose the attached. I'm not sure exactly what subset of ECPG headers is meant to be exposed to clients,

Re: libpq-fe.h should compile *entirely* standalone

2023-03-03 Thread Tom Lane
I wrote: > We can easily do better, as attached, but I wonder which other > headers should get the same treatment. After a bit of further research I propose the attached. I'm not sure exactly what subset of ECPG headers is meant to be exposed to clients, but we can adjust these patterns if new

libpq-fe.h should compile *entirely* standalone

2023-03-03 Thread Tom Lane
I realized that headerscheck is failing to enforce $SUBJECT. This is bad, since we aren't really using libpq-fe.h ourselves in a way that would ensure that c.h symbols don't creep into it. We can easily do better, as attached, but I wonder which other headers should get the same treatment.