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
