Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed atend-of-transaction
От | Fabien COELHO |
---|---|
Тема | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed atend-of-transaction |
Дата | |
Msg-id | alpine.DEB.2.21.2003310723560.16227@pseudo обсуждение исходный текст |
Ответ на | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed atend-of-transaction
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: