Re: pgindent vs dtrace on macos

Daniel Gustafsson <daniel(at)yesql(dot)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