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 [EMAIL PROTECTED] http://yi.org/peter-e/