Re: includedir_internal headers are not self-contained - Mailing list pgsql-hackers

From Tom Lane
Subject Re: includedir_internal headers are not self-contained
Date
Msg-id 19110.1398615538@sss.pgh.pa.us
Whole thread Raw
In response to Re: includedir_internal headers are not self-contained  (Christoph Berg <cb@df7cb.de>)
List pgsql-hackers
Christoph Berg <cb@df7cb.de> writes:
> Re: Tom Lane 2014-04-26 <21449.1398524746@sss.pgh.pa.us>
>> Clearly, the idea that common/ is server-only is broken.

> The next step should probably be something like this:

Somebody who's spent more time than I have on the "make install" support
will have to comment on this patch (Peter?).  I'll just note that the MSVC
build scripts would presumably need parallel fixes.

> Depending on when 9.4 is coming out, Debian Jessie will probably be
> releasing with 9.3. How much of these fixes could we expect to be
> backported to 9.3?

As you saw, I backported the palloc.h fix already.  My current thought
about the relpath.h mess is to fix it in HEAD, but not in 9.3: it'll be
rather invasive for a back-patch, and I doubt it'd be solving a real
problem since IMO no client-side code should be including that header
anyway.  You could just look the other way as far as the dangling
#includes go, or you could choose to remove relpath.h from the installed
non-server header fileset in your package-building script.

As for the proposed change in the set of installed header files,
my vote would probably be not to backport that; I think the risk of
breaking existing packaging recipes in a minor release outweighs
any likely benefit of adding these headers.


>>> (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.

> Maybe a derived header file generated at build time?
> grep '^#define.*OID\>' catalog/pg_type.h > common/pg_staticoids.h

Well, we need a debate first about what we're going to do and what set
of type OIDs we want to expose this way.  There might be a case for
exposing everything listed in pg_type.h (a la fmgroids.h), or maybe it
had better be more restricted.  But a simple grep as above would make
the exposed set dependent on the historical whims of backend coding,
which doesn't seem like a great plan.

There's also reason to think about whether we shouldn't expose
fixed function OIDs in the same way.  One need look no further than
src/interfaces/libpq/fe-lobj.c for client-side code that would greatly
appreciate being allowed to depend on constants from fmgroids.h.

In any case, this issue has been complained of off-and-on for at least
a dozen years.  I feel no urgency to fix it in 9.4, which is already
past feature freeze, so there's not time for a well-considered solution.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: includedir_internal headers are not self-contained
Next
From: Tom Lane
Date:
Subject: So why is EXPLAIN printing only *plan* time?