From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me> |
Subject: | Re: Preliminary results for proposed new pgindent implementation |
Date: | 2017-05-19 18:54:54 |
Message-ID: | 25566.1495220094@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> What I was just looking at is the possibility of absorbing struct
> tags ("xllist" in the above) as if they were typedef names. In
> at least 95% of our usages, if a struct has a tag then the tag is
> also the struct's typedef name. The reason this is interesting
> is that it looks like (on at least Linux and macOS) the debug info
> captures struct tags even when it misses the corresponding typedef.
> We could certainly create a coding rule that struct tags *must*
> match struct typedef names for our own code, but I'm not sure what
> violations of that convention might appear in system headers.
I did an experiment with seeing what would happen to the typedef list
if we included struct tags. On my Linux box, that adds about 10%
more names (3343 instead of 3028). A lot of them would be good to
have, but there are a lot of others that maybe not so much. See
attached diff output.
I hesitate to suggest any rule as grotty as "take struct tags only
if they begin with an upper-case letter", but that would actually
work really well, looks like.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
typedefs.added | text/x-diff | 16.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-05-19 19:04:42 | Re: Event triggers + table partitioning cause server crash in current master |
Previous Message | Bruce Momjian | 2017-05-19 17:37:44 | Re: release note addition |