Re: includedir_internal headers are not self-contained

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christoph Berg <cb(at)df7cb(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: includedir_internal headers are not self-contained
Date: 2014-04-27 16:18:58
Message-ID: 19110.1398615538@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christoph Berg <cb(at)df7cb(dot)de> writes:
> Re: Tom Lane 2014-04-26 <21449(dot)1398524746(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-27 17:07:49 So why is EXPLAIN printing only *plan* time?
Previous Message Christoph Berg 2014-04-27 15:32:39 Re: includedir_internal headers are not self-contained