Date: Mon, 30 Mar 2020 07:16:17 +0200 (CEST)
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, 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: <20200329201215.GM20103@telsasoft.com>
Message-ID: <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>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Precedence: bulk


Hello Justin,

>> Well, the following comment says "ignore anything but regular files",
>> so I'm supposing that that is the behavior that we actually want here
>> and failed to implement correctly.  There might be scope for
>> additional directory-reading functions, but I'd think you'd want
>> more information (such as the file type) returned from anything
>> that doesn't act this way.
>
> Maybe pg_stat_file() deserves similar attention ?  Right now, it'll fail on a
> broken link.  If we changed it to lstat(), then it'd work, but it'd also show
> metadata for the *link* rather than its target.

Yep. I think this traditional answer is the rational answer.

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.

It would reduce the amount of C code and I find the SQL-level approach 
quite elegant.

-- 
Fabien.