Hello,
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.
My 0.02€:
I agree that it is enough to reproduce the current behavior of various
existing pg_ls* functions, but on the other hand outputing a column type
char like ls (-, d, l…) looks like really no big deal. I'd say that the
only reason not to do it may be to pass this before feature freeze.
--
Fabien.
