Re: pgindent weirdness
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-04-20T16:38:57Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Latest consolidated typedef list from buildfarm.
- fe1438da8aa8 9.1.0 cited
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