Re: [HACKERS] Plan for straightening out the include-file mess - Mailing list pgsql-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
defined.


-alex

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            | http://www.acecape.com/dsl
CTO - Acecape, Inc.     | AceDSL:The best ADSL in Bell Atlantic area
325 W 38 St. Suite 1005 | (Stealth Marketing Works! :)
New York, NY 10018      |