Re: pgindent weirdness

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-04-20T16:29:02Z
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 →
  1. Latest consolidated typedef list from buildfarm.

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

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