On Tue, Mar 03, 2020 at 05:23:13PM -0300, Alvaro Herrera wrote:
> 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 be shown at all, or only files ?
>
> 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 example in the initial email, it would look like
>
> path isdir
> pgsql_tmp11025.0.sharedfileset/ t
> pgsql_tmp11025.0.sharedfileset/0.0 f
> pgsql_tmp11025.0.sharedfileset/1.0 f
>
> plus additional columns, same as pg_ls_waldir et al.
>
> I'd rather not have the code assume that there's a single level of
> subdirs, or assuming that an entry in the subdir cannot itself be a dir;
> that might end up hiding files for no good reason.
>
Thanks for your input, see attached.
I'm not sure if prefer the 0002 patch alone (which recurses into dirs all at
once during the initial call), or 0002+3+4, which incrementally reads the dirs
on each call (but requires keeping dirs opened).
> I don't understand what purpose is served by having pg_ls_waldir() hide
> directories.
We could talk about whether the other functions should show dirs, if it's worth
breaking their return type. Or if they should show hidden or special files,
which doesn't require breaking the return. But until then I am to leave the
behavior alone.
--
Justin
