On 04/20/2011 12:29 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.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.)
I believe so. I don't see how it could get tagged in the tables otherwise.
> That's probably fine, because otherwise we'd have the typedef list
> cluttered with junk we don't care about from system headers.
Well, yes, except that I'm a tiny bit smarter than that :-) After we
generate the list of symbols we check that they actually occur in our
sources and filter them out if they don't. That reduces the list by
quite a lot.
> 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.
>
>
That sounds right.
cheers
andrew