Christoph Berg <c...@df7cb.de> writes: > internal/postgres_fe.h includes > common/fe_memutils.h which includes > utils/palloc.h
Hm. It seems rather fundamentally broken to me that frontend code is including palloc.h --- that file was never intended to be frontend-safe, and the #ifdefs that I see in it today don't fill me with any feeling of quality workmanship. I think what we ought to do about this is get rid of the dependency on palloc.h. > Both common/ and utils/ are server-only, so you can't build client > apps which need postgres_fe.h with only libpq-dev installed. Clearly, the idea that common/ is server-only is broken. > I believe common/ should be also be installed by includedir_internal. > utils/ should probably also be installed there, alternatively only the > headers referred to from common/, the files directly referred being: > $ grep -r include 9.4/server/common/ | grep \" > 9.4/server/common/fe_memutils.h:#include "utils/palloc.h" > 9.4/server/common/relpath.h:#include "catalog/catversion.h" /* pgrminclude > ignore */ > 9.4/server/common/relpath.h:#include "storage/relfilenode.h" The catversion dependency also seems pretty damn brain-dead in this context. Let's see if we can get rid of that. As for relfilenode, if we need that in relpath.h maybe the answer is that relfilenode.h has to be in common/. Anyway, the bottom line for me is that utils/ is a server-only area and therefore nothing in common/ ought to depend on it. > (Another issue is that client apps frequently seem to want > catalog/pg_type.h to get the OID definitions, it might make sense to > move that also to internal/.) That's not happening. We do need some better solution for letting client apps get hold of fixed type oids, but moving a catalog header someplace else is not it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers