Re: [HACKERS] Plan for straightening out the include-file mess
От | Alex Pilosov |
---|---|
Тема | Re: [HACKERS] Plan for straightening out the include-file mess |
Дата | |
Msg-id | Pine.BSO.4.10.10102081746270.10185-100000@spider.pilosoft.com обсуждение исходный текст |
Ответ на | Plan for straightening out the include-file mess (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 |
В списке pgsql-interfaces по дате отправления: