Tom Lane writes:
> where the include files have these roles:
This plan looks good in general. It's the same I've been pondering for a
while. But maybe this should receive more extensive thought than what
would be appropriate to implement now.
> postgres_ext.h: definitions needed in frontend, backend, *and* by clients;
> by design an extremely small file
The problem here will be that when we move to 8 byte oids as an option
this file will depend on config.h, so this "design" will break. I have
worked on a private branch with 8 byte oids a while ago and stumbled over
this.
This is only part of a larger problem, namely that over time it gets more
likely that some public header file will depend on config.h. For example,
the libpq++ one's already do. The SSL support in libpq currently requires
the user to define USE_SSL themselves. int8 support in ecpg also requires
configuration information.
Installing config.h is a pretty drastic namespace violation. No other
package that links against some PostgreSQL component can use Autoconf out
of the box.
This "may I install config.h" is a very heated debate around the autotools
discussion fora. I don't see a consensus, but most people agree that you
need to butcher config.h is some way before installing it, like prefixing
all defines with a string, and renaming the file to <package>-config.h.
>
> postgres.h: backend-wide definitions
>
> postgres_fe.h: definitions common to all client-side interface libraries
>
> c.h: basic typedefs and macros needed by both frontend and backend, but
> not intended to be exported to clients of frontend libraries
>
> config.h: configuration definitions, not intended to be client-visible
>
> os.h: platform-specific configuration hacks, not intended to be
> client-visible (this comes from one of the src/include/port files)
>
> config.h and os.h don't need to change, I think, but I'll go through the
> definitions in the other four files and make sure everything is classified
> reasonably.
>
> It's possible that postgres_fe.h will end up containing nothing except
> the inclusions of postgres_ext.h and c.h, in which case we wouldn't really
> need to invent that file, but I'm still inclined to do so. I think it's
> good practice to have a single include file that's the basic "must haves"
> for all client-side code.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
