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 1jhqL9-00012c-Cm for pgsql-hackers@arkaria.postgresql.org; Sun, 07 Jun 2020 08:07:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jhqL7-0002UI-Ce for pgsql-hackers@arkaria.postgresql.org; Sun, 07 Jun 2020 08:07:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhqL6-0002UB-Vp for pgsql-hackers@lists.postgresql.org; Sun, 07 Jun 2020 08:07:32 +0000 Received: from courriel-2.mines-paristech.fr ([77.158.173.19] helo=antispam-1.ensmp.fr) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhqL0-00018P-99 for pgsql-hackers@postgresql.org; Sun, 07 Jun 2020 08:07:31 +0000 Received: from smtp-5.mines-paristech.fr (smtp.mines-paristech.fr [77.158.173.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by antispam-1.ensmp.fr (antispam.mines-paristech.fr) with ESMTPS id D384155E33; Sun, 7 Jun 2020 10:07:21 +0200 (CEST) Received: from pseudo (159.237.219.88.rev.sfr.net [88.219.237.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-5.mines-paristech.fr (Postfix) with ESMTPSA id 2E66820143; Sun, 7 Jun 2020 10:07:21 +0200 (CEST) Date: Sun, 7 Jun 2020 10:07:19 +0200 (CEST) From: Fabien COELHO X-X-Sender: fabien@pseudo To: Justin Pryzby cc: Alvaro Herrera , David Steele , pgsql-hackers@postgresql.org, "Bossart, Nathan" , Thomas Munro , Tom Lane Subject: Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*) In-Reply-To: <20200526021003.GW4472@telsasoft.com> Message-ID: References: <20200316214806.GQ26184@telsasoft.com> <20200316221736.GA15635@alvherre.pgsql> <20200317031427.GU26184@telsasoft.com> <20200317190401.GY26184@telsasoft.com> <20200331200812.GI14618@telsasoft.com> <20200503024215.GJ28974@telsasoft.com> <20200526021003.GW4472@telsasoft.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-CLAMAV-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeglecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffujgfkfhgfgggtsehttdertddtredvnecuhfhrohhmpefhrggsihgvnhcuvefqgffnjffquceotghovghlhhhosegtrhhirdgvnhhsmhhprdhfrheqnecuggftrfgrthhtvghrnhepveefgfeuhfegfeffueeljeefjeevgfffleevleekgfduieeftdfgudffledvjeeinecukfhppeekkedrvdduledrvdefjedrudehleenucfrrghrrghmpehmohguvgepshhmthhpohhuth X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello Justin, > Rebased onto 7b48f1b490978a8abca61e9a9380f8de2a56f266 and renumbered OIDs. Some feedback about v18, seen as one patch. Patch applies cleanly & compiles. "make check" is okay. pg_stat_file() and pg_stat_dir_files() now return a char type, as well as the function which call them, but the documentation does not seem to say that it is the case. I must admit that I'm not a fan on the argument management of pg_ls_dir_metadata and pg_ls_dir_metadata_1arg and others. I understand that it saves a few lines though, so maybe let it be. There is a comment in pg_ls_dir_files which talks about pg_ls_dir. Could pg_ls_*dir functions C implementations be dropped in favor of a pure SQL implementation, like you did with recurse? If so, ISTM that pg_ls_dir_files() could be significantly simplified by moving its filtering flag to SQL conditions on "type" and others. That could allow not to change the existing function output a keep the "isdir" column defined as "type = 'd'" where it was used previously, if someone complains, but still have the full capability of "ls". That would also allow to drop the "*_1arg" hacks. Basically I'm advocating having 1 or 2 actual C functions, and all other variants managed at the SQL level. -- Fabien.