Re: pgindent vs dtrace on macos - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgindent vs dtrace on macos
Date
Msg-id 187727.1600357196@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgindent vs dtrace on macos  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: pgindent vs dtrace on macos  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
>>> On that note, I
>>> wonder if we should add the plperl .xs generated files as exclusions too since
>>> we don't control that generator?

>> Not an issue I don't think; pgindent won't touch extensions other than
>> .c and .h.

> Sorry for being unclear, I meant the generated .c counterpart of the .xs file.

Oh, I see.  Not sure.  For myself, I only care about files that survive
"make distclean" and get into a tarball, which those don't.  On the
other hand, if we fixed perlchunks.h and plperl_opmask.h then it's hard
to argue with worrying about SPI.c and Util.c, as those all have the
same lifespan.

I tried redoing the experiment of pgindenting all the tarball member
files, and found that we still have diffs in these generated files:

src/backend/utils/sort/qsort_tuple.c
src/common/kwlist_d.h
src/interfaces/ecpg/preproc/c_kwlist_d.h
src/interfaces/ecpg/preproc/ecpg_kwlist_d.h
src/pl/plpgsql/src/pl_reserved_kwlist_d.h
src/pl/plpgsql/src/pl_unreserved_kwlist_d.h
src/pl/plpgsql/src/plerrcodes.h
src/pl/plpython/spiexceptions.h
src/pl/tcl/pltclerrcodes.h

To my eyes, what pgindent does to the *kwlist_d.h files is rather ugly,
so I'm inclined to make them exclusions rather than adjust the generator
script.  The others seem like we could tweak the relevant generators
fairly easily.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Next
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes