Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIw0x-0004iw-6y for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Sep 2020 15:40:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kIw0v-0008Ne-Ad for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Sep 2020 15:40:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIw0v-0008NL-47 for pgsql-hackers@lists.postgresql.org; Thu, 17 Sep 2020 15:40:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIw0s-0004Mk-Vi for pgsql-hackers@postgresql.org; Thu, 17 Sep 2020 15:40:00 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 08HFduui187728; Thu, 17 Sep 2020 11:39:56 -0400 From: Tom Lane To: Daniel Gustafsson cc: Peter Eisentraut , pgsql-hackers Subject: Re: pgindent vs dtrace on macos In-reply-to: <2876D3E9-AD31-4841-869B-CADDBF2EBC66@yesql.se> References: <79ed5348-be7a-b647-dd40-742207186a22@2ndquadrant.com> <21042.1589983015@sss.pgh.pa.us> <43461.1600300517@sss.pgh.pa.us> <2876D3E9-AD31-4841-869B-CADDBF2EBC66@yesql.se> Comments: In-reply-to Daniel Gustafsson message dated "Thu, 17 Sep 2020 10:15:30 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <187726.1600357196.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Sep 2020 11:39:56 -0400 Message-ID: <187727.1600357196@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Daniel Gustafsson writes: >>> On that note, I >>> wonder if we should add the plperl .xs generated files as exclusions t= oo 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