From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: simplehash vs. pgindent |
Date: | 2016-12-21 09:28:05 |
Message-ID: | 20161221092805.236tvigc2vzodwbw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-12-21 00:32:22 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > In commit b30d3ea824c5ccba43d3e942704f20686e7dbab8, when Andres added
> > the simplehash stuff, he also added SH_TYPE, SH_ITERATOR, and
> > SH_STATUS to typedefs.list. When I subsequently updated typedefs.list
> > from the buildfarm in acddbe221b084956a0efd6e4b6c6586e8fd994d7, it of
> > course removed those entries since they are merely placeholders for
> > real types, not anything that would ever appear in a symbol table. So
> > now if you pgindent the simplehash stuff, it does stupid things.
> > I think we should add a file src/tools/pgindent/typedefs.extra.list.
> > Somehow teach pgindent to search whatever directory it searches for
> > typedefs.list for typedefs.extra.list as well. Then we can put stuff
> > in there that the buildfarm doesn't find, and pgindent can combine the
> > files in load_typedefs(). That way we can still update typedefs.list
> > straight from the buildfarm, but there's a place to put manual entries
> > that we don't want to lose. We could also teach load_typedefs() to
> > strip out lines that are empty or start with #, and then we'd be able
> > to put comments in typedefs.extra.list explaining why each entry needs
> > to be present there rather than relying on the normal mechanism.
That sounds sane.
> Or we could just fix the code so it doesn't use phony typedefs?
> If a typedef is never used as a variable or field type, how much
> do we really need it?
I'm not sure what you mean by that. The typedefs are used, it's just
that the resultof the macros (aforementioned SH_TYPE etc) are named
differently than the macro name itself, and thus it's not contained in
the generated typedefs list.
We obviously can add a 'struct ' everywhere, but that doesn't really
seem to conform to style?
Regards,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-12-21 09:53:21 | Re: Parallel bitmap heap scan |
Previous Message | Craig Ringer | 2016-12-21 09:24:35 | Re: SET NOT NULL [NOT VALID / CONCURRENTLY]? |