Re: pgindent vs dtrace on macos

> On 22 May 2020, at 11:29, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
> On 2020-05-20 15:56, Tom Lane wrote:

>> I wonder if we should make an effort to ensure
>> that our generated .h and .c files always satisfy pgindent.
>
> We should generally try to do that, if only so that they don't appear weird and random when looking at them.

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:

@@ -912,7 +912,7 @@
 extern Datum interval_mul(PG_FUNCTION_ARGS);
 extern Datum pg_typeof(PG_FUNCTION_ARGS);
 extern Datum ascii(PG_FUNCTION_ARGS);
-extern Datum chr(PG_FUNCTION_ARGS);
+extern Datum chr (PG_FUNCTION_ARGS);
 extern Datum repeat(PG_FUNCTION_ARGS);
 extern Datum similar_escape(PG_FUNCTION_ARGS);
 extern Datum mul_d_interval(PG_FUNCTION_ARGS);
@@ -968,7 +968,7 @@
 extern Datum bitsubstr_no_len(PG_FUNCTION_ARGS);
 extern Datum numeric_in(PG_FUNCTION_ARGS);
 extern Datum numeric_out(PG_FUNCTION_ARGS);
-extern Datum numeric(PG_FUNCTION_ARGS);
+extern Datum numeric (PG_FUNCTION_ARGS);
 extern Datum numeric_abs(PG_FUNCTION_ARGS);
 extern Datum numeric_sign(PG_FUNCTION_ARGS);
 extern Datum numeric_round(PG_FUNCTION_ARGS);

Not sure what pgindent is doing there, but it seems hard to address in the
generator.

probes.h is also added to the exclusion list in the patch.  On that note, I
wonder if we should add the plperl .xs generated files as exclusions too since
we don't control that generator?

cheers ./daniel