Re: pgindent weirdness

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgindent weirdness
Date: 2011-04-20 16:29:02
Message-ID: 28426.1303316942@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> But in any case, *none* of the individual files knows about
> BulkInsertStateData as a typedef:
> ...
> And the reason is actually fairly obvious on closer inspection. The only
> place we actually use the BulkInsertStateData typedef (as opposed to the
> struct declaration) is here:

> ./backend/access/heap/heapam.c: bistate = (BulkInsertState)
> palloc(sizeof(BulkInsertStateData));

> and that sizeof operation will be resolved at compile time and never hit
> the symbol table.

Oh, interesting. So you're saying that for this mechanism to know that
"foo" is a typedef, there has to be at least one variable in the code
that's declared as being of type foo or foo *? (Where "variable" would
include function parameters, fields of other structs, etc.)

That's probably fine, because otherwise we'd have the typedef list
cluttered with junk we don't care about from system headers.

So in the case at hand, we actually *need* to remove the "struct" from
RelationGetBufferForTuple's declaration, so that BulkInsertStateData
gets used as a typedef name in that way.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-04-20 16:33:26 Re: pgindent weirdnessf
Previous Message Andrew Dunstan 2011-04-20 16:23:11 Re: pgindent weirdness