From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
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: <alpine.DEB.2.21.2003300704430.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>
Comments: In-reply-to Fabien COELHO <coelho@cri.ensmp.fr>
	message dated "Mon, 30 Mar 2020 07:16:17 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4027.1585579463.1@sss.pgh.pa.us>
Date: Mon, 30 Mar 2020 10:44:23 -0400
Message-ID: <4028.1585579463@sss.pgh.pa.us>
Precedence: bulk

Fabien COELHO <coelho@cri.ensmp.fr> writes:
> 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.

			regards, tom lane