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.