Re: includedir_internal headers are not self-contained

Christoph Berg <cb(at)df7cb(dot)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