Re: pgindent vs dtrace on macos

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgindent vs dtrace on macos
Date: 2020-09-17 08:15:30
Message-ID: 2876D3E9-AD31-4841-869B-CADDBF2EBC66@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> The attached patch fixes the generation of sql_help.h and perl_opmask.h to make
>>> sure they conform to pgindent. Those were the only file I got diffs in after a
>>> pgindent run apart from fmgrprotos.h which gave the below:
>
>> Hmm, I seem to recall there were more when this happened to me back in
>> May. But in any case, fixing these is an improvement.
>
> Experimenting with this patch soon found one additional case: sql_help.c,
> also emitted by create_help.pl, also needs some whitespace help.
> I do not recall if there are other places, but fixing these is
> surely a step forward. I fixed the sql_help.c output and pushed it.

Thanks! I think a bug for .c and .h files with matching names in my small
script testing for discrepancies hid that one.

>> 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.
So something like the below:

--- a/src/tools/pgindent/exclude_file_patterns
+++ b/src/tools/pgindent/exclude_file_patterns
@@ -5,6 +5,8 @@
/ecpg/test/expected/
/snowball/libstemmer/
/pl/plperl/ppport\.h$
+/pl/plperl/SPI\.c$
+/pl/plperl/Util\.c$
/jit/llvmjit\.h$
/utils/probes\.h$
/tmp_check/

cheers ./daniel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleksandr Shulgin 2020-09-17 08:20:16 Re: Concurrency issue in pg_rewind
Previous Message yuzuko 2020-09-17 08:12:36 Re: Autovacuum on partitioned table (autoanalyze)