Date: Tue, 31 Mar 2020 07:36:03 +0200 (CEST)
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org,
    Alvaro Herrera <alvherre@2ndquadrant.com>,
    David Steele <david@pgmasters.net>,
    "Bossart,    Nathan" <bossartn@amazon.com>,
    Thomas Munro <thomas.munro@gmail.com>
Subject: Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at
 end-of-transaction
In-Reply-To: <4028.1585579463@sss.pgh.pa.us>
Message-ID: <alpine.DEB.2.21.2003310723560.16227@pseudo>
References: <20200312121156.GB29065@telsasoft.com>
 <20200316155306.GM26184@telsasoft.com> <3061.1584409130@sss.pgh.pa.us>
 <20200317020017.GT26184@telsasoft.com> <24244.1585415634@sss.pgh.pa.us>
 <20200328183904.GI20103@telsasoft.com> <28906.1585422475@sss.pgh.pa.us>
 <27064.1585499825@sss.pgh.pa.us> <20200329171415.GL20103@telsasoft.com>
 <29512.1585502524@sss.pgh.pa.us> <20200329201215.GM20103@telsasoft.com>
 <alpine.DEB.2.21.2003300704430.16227@pseudo> <4028.1585579463@sss.pgh.pa.us>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="2056645051-373064571-1585632965=:16227"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--2056645051-373064571-1585632965=:16227
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT


Hello,

>> As I wrote about an earlier version of the patch, ISTM that instead of
>> reinventing, extending, adapting various ls variants (with/without
>> metadata, which show only files, which shows target of links, which shows
>> directory, etc.) we would just need *one* postgres "ls" implementation
>> which would be like "ls -la arg" (returns file type, dates), and then
>> everything else is a wrapper around that with appropriate filtering that
>> can be done at the SQL level, like you started with recurse.
>
> Yeah, I agree that some new function that can represent symlinks
> explicitly in its output is the place to deal with this, for
> people who want to deal with it.
>
> In the meantime, there's still the question of what pg_ls_dir_files
> should do exactly.  Are we content to have it ignore symlinks?
> I remain inclined to think that's the right thing given its current
> brief.

My 0.02€:

I agree that it is enough to reproduce the current behavior of various 
existing pg_ls* functions, but on the other hand outputing a column type 
char like ls (-, d, l…) looks like really no big deal. I'd say that the 
only reason not to do it may be to pass this before feature freeze.

-- 
Fabien.
--2056645051-373064571-1585632965=:16227--