On 3/3/20, 12:24 PM, "Alvaro Herrera" wrote:
> 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
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 b
On Tue, Mar 03, 2020 at 02:51:54PM -0500, David Steele wrote:
> Hi Fabien,
>
> On 1/16/20 9:38 AM, Justin Pryzby wrote:
> >On Thu, Jan 16, 2020 at 09:34:32AM +0100, Fabien COELHO wrote:
> >>Also, I'm not fully sure why ".*" files should be skipped, maybe it should
> >>be an option? Or the user can
Hi Fabien,
On 1/16/20 9:38 AM, Justin Pryzby wrote:
On Thu, Jan 16, 2020 at 09:34:32AM +0100, Fabien COELHO wrote:
Also, I'm not fully sure why ".*" files should be skipped, maybe it should
be an option? Or the user can filter it with SQL if it does not want them?
I think if someone wants the
On Thu, Jan 16, 2020 at 09:34:32AM +0100, Fabien COELHO wrote:
> Also, I'm not fully sure why ".*" files should be skipped, maybe it should
> be an option? Or the user can filter it with SQL if it does not want them?
I think if someone wants the full generality, they can do this:
postgres=# SELEC
Hello Justin,
I'm trying to think about how to get rid of the strange structure and hacks,
and the arbitrary looking size 2 array.
Also the recursion is one step, but I'm not sure why, ISTM it could/should
go on always?
Because tmpfiles only go one level deep.
I'm not sure it is a general
On Wed, Jan 15, 2020 at 11:21:36AM +0100, Fabien COELHO wrote:
> I'm trying to think about how to get rid of the strange structure and hacks,
> and the arbitrary looking size 2 array.
>
> Also the recursion is one step, but I'm not sure why, ISTM it could/should
> go on always?
Because tmpfiles o
Hello Justin,
About this v4.
It applies cleanly.
I'm trying to think about how to get rid of the strange structure and
hacks, and the arbitrary looking size 2 array.
Also the recursion is one step, but I'm not sure why, ISTM it could/should
go on always?
Maybe the recursive implementati
Here's a version which uses an array of directory_fctx, rather than of DIR and
location. That avoids changing the data structure and collatoral implications
to pg_ls_dir().
Currently, this *shows* subdirs of subdirs, but doesn't decend into them.
So I think maybe toplevel subdirs should be shown,
Hello Justin,
Ok, so this suggests recursing into subdirs, which requires to make a
separate function of the inner loop.
Yea, it suggests that; but, SRF_RETURN_NEXT doesn't make that very easy.
It'd need to accept the fcinfo argument, and pg_ls_dir_files would call it once
for every tuple to
On Sat, Dec 28, 2019 at 07:52:55AM +0100, Fabien COELHO wrote:
> >>Why not simply showing the files underneath their directories?
> >>
> >> /path/to/tmp/file1
> >> /path/to/tmp/subdir1/file2
> >>
> >>In which case probably showing the directory itself is not useful,
> >>and the is_dir column coul
Hello Justin,
Why not simply showing the files underneath their directories?
/path/to/tmp/file1
/path/to/tmp/subdir1/file2
In which case probably showing the directory itself is not useful,
and the is_dir column could be dropped?
The names are expected to look like this:
$ sudo find /v
On Fri, Dec 27, 2019 at 06:50:24PM +0100, Fabien COELHO wrote:
> >On Fri, Dec 27, 2019 at 05:22:47PM +0100, Fabien COELHO wrote:
> >>The implementation simply extends an existing functions with a boolean to
> >>allow for sub-directories. However, the function does not seem to show
> >>subdir conten
Re-added -hackers.
Indeed, I left it out by accident. I tried to bounce the original mail but
it did not work.
Thanks for reviewing.
On Fri, Dec 27, 2019 at 05:22:47PM +0100, Fabien COELHO wrote:
The implementation simply extends an existing functions with a boolean to
allow for sub-dir
Re-added -hackers.
Thanks for reviewing.
On Fri, Dec 27, 2019 at 05:22:47PM +0100, Fabien COELHO wrote:
> The implementation simply extends an existing functions with a boolean to
> allow for sub-directories. However, the function does not seem to show
> subdir contents recursively. Should it be
15 matches
Mail list logo