Downsides of scanning all .o files for typedefs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Downsides of scanning all .o files for typedefs
Date: 2014-04-06 16:06:19
Message-ID: 15199.1396800379@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'd been getting weird results for the last couple of days while
pgindent-ing various patches. I eventually realized that the cause
was that the current typedefs list marks "c", "string", and a few
other common words as typedefs. This seems pretty uncool. Further
investigation shows that the reason is that these names are used as
typedefs in a couple of the ecpg regression tests; which the old
find_typedefs code never picked up on, but the OS X implementation
does.

Now, it's actually rather pointless to collect typedef names from
the ecpg tests, since pgindent won't process files with .pgc
extensions anyway (and I doubt it would work well to try).

So we could either revise these test cases to use less-generic
typedef names, or we could just skip ecpg/test/ in find_typedefs.
For the moment I've got dromedary using the attached quick-hack patch
to do the latter. Any thoughts on the best long-term answer?

regards, tom lane

Attachment Content-Type Size
dont-find-typedefs-in-ecpg-tests.patch text/x-diff 799 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-06 17:23:21 FastPathStrongRelationLocks still has an issue in HEAD
Previous Message Geoff Montee 2014-04-06 14:03:24 tds_fdw for Sybase and MS SQL Server