Skip site navigation (1) Skip section navigation (2)

Re: Plan for straightening out the include-file mess

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>, <pgsql-interfaces(at)postgreSQL(dot)org>
Subject: Re: Plan for straightening out the include-file mess
Date: 2001-02-09 00:08:53
Message-ID: Pine.LNX.4.30.0102090004280.1362-100000@peter.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
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(at)gmx(dot)net       http://yi.org/peter-e/


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-02-09 00:10:50
Subject: Re: Plan for straightening out the include-file mess
Previous:From: Alex PilosovDate: 2001-02-08 23:40:21
Subject: Re: Plan for straightening out the include-file mess

pgsql-interfaces by date

Next:From: Tom LaneDate: 2001-02-09 00:10:50
Subject: Re: Plan for straightening out the include-file mess
Previous:From: Alex PilosovDate: 2001-02-08 23:40:21
Subject: Re: Plan for straightening out the include-file mess

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group