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 <akorot...@postgresql.org> Date: 2020-03-30 19:17:11 +0300 Implement operator class parameters