Hi,
I noticed that postgres.h is included from relcache.h (starting in [1]) and
wanted to fix that - it violates our usual policy against including postgres.h
from within headers.
But then I noticed that that causes pg_upgrade/file.c to fail to compile:
In file included from /home/andres/src/postgresql/src/include/access/visibilitymap.h:20,
from /home/andres/src/postgresql/src/bin/pg_upgrade/file.c:22:
/home/andres/src/postgresql/src/include/utils/relcache.h:53:8: error: unknown type name ‘Datum’
53 | extern Datum *RelationGetIndexRawAttOptions(Relation relation);
Which is presumably why the postgres.h include was added in [1]. The only
reason this didn't fail before is because there wasn't any other reference to
Datum (or any of the other postgres.h types) in relcache.h before this commit.
I guess the best solution is to add include the "full" postgres.h explicitly
from file.c like several other places, like e.g. src/bin/pg_controldata/pg_controldata.c
do:
/*
* We have to use postgres.h not postgres_fe.h here, because there's so much
* backend-only stuff in the XLOG include files we need. But we need a
* frontend-ish environment otherwise. Hence this ugly hack.
*/
#define FRONTEND 1
I was also wondering if we should put something in c.h and postgres.h to avoid
redundant includes? Currently there's a few .c files that "use" the header
guards, all scanners that we include into the parsers.
Greetings,
Andres Freund
[1] commit 911e70207703799605f5a0e8aad9f06cff067c63
Author: Alexander Korotkov <akorotkov@postgresql.org>
Date: 2020-03-30 19:17:11 +0300
Implement operator class parameters