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

Re: Plan for straightening out the include-file mess

From: Alex Pilosov <alex(at)acecape(dot)com>
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-08 23:11:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
Great! :)

It might also clean up something that I've been fighting against for
awhile: when I include files needed for SPI, it drags also a lot of other
garbage in, which conflicts with other things (namely, trying to get a
file to simultaneously include SPI and perl headers is impossible). 

I realise it might be a lot of pain to clean up, but, you may consider
having a separate top-level include for SPI, which would not define (by
default) things like DEBUG, USE_LOCALE, union semun, etc. 

IMHO, it should really include only definitions of relevant data
structures which interface with SPI code...

I realize that complete split for SPI/module from "core backend" might be
very hard, so a thing to consider would be to have (like linux kernel code
has) #define IN_CORE (you are welcome to come up with better name), and
include "core backend"-specific things conditionally on that being


On Thu, 8 Feb 2001, Tom Lane wrote:

> I have been looking at making a split between client-side and server-side
> include files as we discussed earlier this week (pghackers thread
> "Include files for SPI are not installed", if you missed it).  It turns
> out that the major issue here is not just divvying up the files; the
> problem is that we have never had a clear concept of such a division
> before, and so the core include files like postgres.h, c.h, config.h
> contain a rather unholy mixture of things that are definitely
> backend-only with things that are relevant to both clients and backends.
> I think we need to start by clarifying the roles of these include files
> and moving their contents around as necessary.
> Currently, almost every .c in the distribution starts out by including
> postgres.h, which in turn includes these other files:
> postgres.h
> 	postgres_ext.h
> 	c.h
> 		config.h
> 			os.h
> 	utils/elog.h
> 	utils/palloc.h
> Now elog.h and palloc.h are server-only facilities and certainly don't
> belong in a client file's include set.  I think what we want to do is
> decree that postgres.h is the primary include file for backend .c files
> only, and that frontend .c files should include something else.
> postgres_ext.h would be a candidate to be that something else, except
> that it's included by libpq-fe.h, so anything we add to postgres_ext.h
> represents namespace pollution for libpq clients.  I think we should be
> very wary about adding a lot of stuff to postgres_ext.h.  This suggests
> that we'd best create a new primary include file for client-side .c files,
> say "postgres_fe.h" or "postgres_client.h".  (Anyone have a better naming
> idea?  Does the old 14-character limit still pose a problem anywhere?)
> That would leave us with include trees like this:
> backend .c file:
> 	postgres.h
> 		postgres_ext.h
> 		c.h
> 			config.h
> 				os.h
> 		utils/elog.h
> 		utils/palloc.h
> frontend .c file:
> 	postgres_fe.h
> 		postgres_ext.h
> 		c.h
> 			config.h
> 				os.h
> where the include files have these roles:
> postgres_ext.h: definitions needed in frontend, backend, *and* by clients;
> 	by design an extremely small file
> 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.
> Now, since the intent is that the basic install provide headers needed
> for client-side programming, we'd want to add postgres_fe.h to the
> installed header set.  But the following files can be removed from the
> basic install:
> access/attnum.h
> commands/trigger.h
> executor/spi.h
> fmgr.h
> postgres.h
> utils/elog.h
> utils/geo_decls.h
> utils/palloc.h
> We might also remove utils/fmgroids.h.  I'm uncertain about this one.
> The function OID macros it contains are potentially useful to clients,
> but do we really want people hard-wiring function OIDs on the client
> side?  I doubt it.
> There are two or three other include files, such as lib/dllist.h, that are
> needed on the client side only because libpq-int.h includes them, and we
> want to support client code that includes libpq-int.h.  I am going to look
> at skinnying that list down too.  libpq-fs.h, in particular, looks like
> mostly legacy junk ...
> As we discussed, there'll be an additional install target (or RPM) that
> installs these files and everything else from the src/include tree.
> Comments?
> 			regards, tom lane

Alex Pilosov            |
CTO - Acecape, Inc.     | AceDSL:The best ADSL in Bell Atlantic area
325 W 38 St. Suite 1005 | (Stealth Marketing Works! :)
New York, NY 10018      |

In response to


pgsql-hackers by date

Next:From: Alex PilosovDate: 2001-02-08 23:15:16
Subject: Re: Plan for straightening out the include-file mess
Previous:From: Tom LaneDate: 2001-02-08 22:50:55
Subject: Re: Syslog and pg_options (for RPMs)

pgsql-interfaces by date

Next:From: Alex PilosovDate: 2001-02-08 23:15:16
Subject: Re: Plan for straightening out the include-file mess
Previous:From: Tom LaneDate: 2001-02-08 22:38:17
Subject: Plan for straightening out the include-file mess

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