Re: Lessons from commit fest

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Chris Browne" <cbbrowne(at)acm(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Lessons from commit fest
Date: 2008-04-18 03:23:42
Message-ID: 8763ufc0ch.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
>> 1) I take it we feel safe guaranteeing that we won't use any fancy macros
>> inside typedefs. So no '#define pgtype(x) _pg_##x' or anythin like that.
>
> Hmm ... we are fairly crawling with struct tags built that way:
>
> /* Introduces a catalog's structure definition */
> #define CATALOG(name,oid) typedef struct CppConcat(FormData_,name)
>
> but offhand I can't think of any actual typedef names built with ##.
> Does indent need a preset list of struct tags? Seems that would be
> stupid ...

It's not just ## that's a problem. Any macro used to build the typedef would
be a problem. There's not a whole lot of other reasons you would want to use
macros in a typedef but...

>> 3) How would this work with typedefs which come from system or library
>> includes?
>
> Ouch, that's a real good point. Maybe a certain amount of platform
> dependence is inevitable.

The reason I was asking these questions was because I was thinking about how
hard it would be to generate the list from a textual analysis instead of using
object files.

Such a tool *cannot* use cpp to preprocess the file because it would defeat
much of the purpose. The point is that we want to find all the typedefs in all
the #ifdef branches.

But if we don't preprocess the files with CPP then macros like the one I
included before wouldn't be interpreted. Nor would we be pulling in system or
library headers, so no typedefs from them.

But if we're just interested in the names I suppose a hybrid approach would
work. 1) The build farm builds a list of typedefs found in all the various
builds and we check that into CVS. 2) a textual tool run as part of your
normal build builds a list of typedefs found in your tree.

But if we're still doing object file analysis on the build farm and it's easy
to add typedefs manually then perhaps there's not much effort saved by having
such a tool. I think it would be possible to write but it wouldn't really be
easy. You have to parse just enough C to find the typedef but not so much you
get confused by invalid C syntax caused by looking at both sides of #ifdef
branches.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-04-18 03:29:55 Re: Lessons from commit fest
Previous Message Alvaro Herrera 2008-04-18 01:57:44 Re: Plan targetlists in EXPLAIN output