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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-interfaces by date

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