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
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 |