Re: pgindent weirdness
От | Andrew Dunstan |
---|---|
Тема | Re: pgindent weirdness |
Дата | |
Msg-id | 4DAF0C21.2070505@dunslane.net обсуждение исходный текст |
Ответ на | Re: pgindent weirdness (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgindent weirdness
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: