Re: Downsides of scanning all .o files for typedefs

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Downsides of scanning all .o files for typedefs
Дата
Msg-id 5341AEA0.3020607@dunslane.net
обсуждение исходный текст
Ответ на Downsides of scanning all .o files for typedefs  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 04/06/2014 12:06 PM, Tom Lane wrote:
> 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?


As you say we're not going to be indenting the .pgc files anyway, so 
this seems like quite a reasonable solution.

cheers

andrew



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: four minor proposals for 9.5
Следующее
От: Rajeev rastogi
Дата:
Сообщение: Re: [review] PostgreSQL Service on Windows does not start if data directory given is relative path