Re: Plan for straightening out the include-file mess

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 |