libpq-fe.h should compile *entirely* standalone
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.
regards, tom lane
Attachments:
test-libpq-fe.h-better.patchtext/x-diff; charset=us-ascii; name=test-libpq-fe.h-better.patchDownload+8-1
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 info emerges.
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?
regards, tom lane
Attachments:
v2-tighten-inclusion-checks.patchtext/x-diff; charset=us-ascii; name=v2-tighten-inclusion-checks.patchDownload+50-2
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, but we can adjust these patterns if new info emerges.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
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> 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, tom lane