From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: David Steele <david@pgmasters.net>
Cc: Bossart, Nathan <bossartn@amazon.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Subject: Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction
Date: Mon, 30 Mar 2020 07:16:17 +0200 (CEST)
Message-ID: <alpine.DEB.2.21.2003300704430.16227@pseudo> (raw)
In-Reply-To: <20200329201215.GM20103@telsasoft.com>
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>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: coelho@cri.ensmp.fr, pryzby@telsasoft.com, tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, david@pgmasters.net, bossartn@amazon.com, 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>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox