On 04/20/2011 12:29 PM, Tom Lane wrote:
Andrew Dunstan<and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers