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/
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 |
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 |