From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Undesirable entries in typedefs list
In-reply-to: <20180324172919.axixlwl2itsk2yx3@alap3.anarazel.de>
References: <28690.1521912334@sss.pgh.pa.us>
 <20180324172919.axixlwl2itsk2yx3@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 24 Mar 2018 10:29:19 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29149.1521912885.1@sss.pgh.pa.us>
Date: Sat, 24 Mar 2018 13:34:45 -0400
Message-ID: <29150.1521912885@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2018-03-24 13:25:34 -0400, Tom Lane wrote:
>> (2) "abs", "boolean", "iterator", "other", "pointer", "reference",
>> "string", and "type" all now are listed as typedef names.
>> 
>> It's probably okay to treat "boolean" as a typedef, but all those others
>> are complete disasters.  Anyone know where they're coming from?

> Semi informed theory: LLVM?  I think I'd configured one of the LLVM
> animals to collect typedefs, but that might have been a bad idea...

That was my first thought as well, since this seems to have changed
quite recently.  I don't think it's a bad idea to be collecting typedefs
from something that compiles that code, because otherwise our own
typedefs in that area won't be known.

>> As for "bool", we could probably deal with that most reliably by
>> having pgindent add it as a special case.  Maybe we could get it
>> back in there by having some trailing-edge buildfarm member
>> contribute typedefs, but that seems like a solution with a rather
>> limited half-life.

> Could we combine the list of typedefs with one manually maintained
> in-tree?

Perhaps.  We might need a manually maintained blacklist, as well.

			regards, tom lane