Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j9tD0-0004g2-Js for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Mar 2020 16:18:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j9tCz-0005Fm-6d for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Mar 2020 16:18:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j9tCy-0005Fa-HB for pgsql-hackers@lists.postgresql.org; Thu, 05 Mar 2020 16:18:48 +0000 Received: from mail-yw1-xc42.google.com ([2607:f8b0:4864:20::c42]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j9tCs-0000Vv-Cg for pgsql-hackers@postgresql.org; Thu, 05 Mar 2020 16:18:46 +0000 Received: by mail-yw1-xc42.google.com with SMTP id a132so6135522ywb.2 for ; Thu, 05 Mar 2020 08:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hoJDo22u+yDe/5B35Ap/EGu8bkiBxUZ3+zzNudziKVI=; b=UAmFpfnqDp75ZEo41/aZCzE07aqSUU7LJ7AyHMdIAS9+P4VuzaXtnauPGc7WzzoQZB UahW523e9c/CUWFq7iiHeEY9UT52aYghXVD1xcFgwljU15y2BcYzxZgCyxn45YLZN7Ow G/pBswhHkbR1Q8BgtGzNk2tICMiWV9SDWZnyMIqlortE3nonrDY2pKJLGTOhRxYJTfKC Boyg6ZhRCOEssSlkphpJNLEHOhzCe3G9r5O06iTsNQCagwfR35LetcAUD4e8WC1XLtmv 7ZODjRPmBPz683uf2t1AZ4siNjWtfZUMNJFbn7tEAoYRXzm/FUeagxD3+hrZXqBv3YJ4 T3Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hoJDo22u+yDe/5B35Ap/EGu8bkiBxUZ3+zzNudziKVI=; b=Ew0QxOyrh6923/zZPa5cHBTZqR0XZd+QQDSOjy3hb9OhZgUJB0FeNKbQEX9dYsMbnQ kWItWYqDTSJ+N++74Lc5cssQQnD8nlvJY4hVccLJyJfWlwNNCZ7bqc3cazpd8Dfq+Dko 4BH2cXjnjmQyox8KpkiLH0XpDFUAe3uLAEor31FUFiAKVYPhBctEKmXXII8fBr4uL2CO Cc6KPfoQ46k6cG858IpWk3q1KHi4G5jJhqw4LZT7XSOIqVgg8XaTmjRKElQiDkLr/gFA /87yvvlXomQvK8SZ46KBI5npXI4cUc9dpTXDD78Rjf7CbTPNXeGJyYynMMwh3npGH4lE Or5g== X-Gm-Message-State: ANhLgQ2L0SPas0xZSzabBkd0sFZLQDqSfA+LbbPVWf52UvQIQsmwBhfJ 3VO3m5Ji7NLjkA6uFqemKXpowg== X-Google-Smtp-Source: ADFU+vvf4vBUWYPWg1MRm9QS9vdbgO0tQ2Df3bgxbRloJV3t1B2f99rB0GkZqYwQ4gnVaD6sLG1Vdw== X-Received: by 2002:a25:2f43:: with SMTP id v64mr8960937ybv.71.1583425121359; Thu, 05 Mar 2020 08:18:41 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id d9sm12261266ywh.55.2020.03.05.08.18.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2020 08:18:40 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id B4B388009F4; Thu, 5 Mar 2020 10:18:38 -0600 (CST) Date: Thu, 5 Mar 2020 10:18:38 -0600 From: Justin Pryzby To: Alvaro Herrera Cc: David Steele , Fabien COELHO , pgsql-hackers@postgresql.org, "Bossart, Nathan" , Thomas Munro Subject: Re: pg_ls_tmpdir to show directories and shared filesets Message-ID: <20200305161838.GJ684@telsasoft.com> References: <20200303200117.GI684@telsasoft.com> <20200303202313.GA28076@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline In-Reply-To: <20200303202313.GA28076@alvherre.pgsql> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 03, 2020 at 05:23:13PM -0300, Alvaro Herrera wrote: > On 2020-Mar-03, Justin Pryzby wrote: > > > But I don't think it makes sense to go through more implementation/review > > cycles without some agreement from a larger group regarding the > > desired/intended interface. Should there be a column for "parent dir" ? Or a > > column for "is_dir" ? Should dirs be shown at all, or only files ? > > IMO: is_dir should be there (and subdirs should be listed), but > parent_dir should not appear. Also, the "path" should show the complete > pathname, including containing dirs, starting from whatever the "root" > is for the operation. > > So for the example in the initial email, it would look like > > path isdir > pgsql_tmp11025.0.sharedfileset/ t > pgsql_tmp11025.0.sharedfileset/0.0 f > pgsql_tmp11025.0.sharedfileset/1.0 f > > plus additional columns, same as pg_ls_waldir et al. > > I'd rather not have the code assume that there's a single level of > subdirs, or assuming that an entry in the subdir cannot itself be a dir; > that might end up hiding files for no good reason. > Thanks for your input, see attached. I'm not sure if prefer the 0002 patch alone (which recurses into dirs all at once during the initial call), or 0002+3+4, which incrementally reads the dirs on each call (but requires keeping dirs opened). > I don't understand what purpose is served by having pg_ls_waldir() hide > directories. We could talk about whether the other functions should show dirs, if it's worth breaking their return type. Or if they should show hidden or special files, which doesn't require breaking the return. But until then I am to leave the behavior alone. -- Justin --V88s5gaDVPzZ0KCq Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v6-0001-BUG-in-errmsg.patch"