Re: pg_ls_tmpdir to show directories and shared filesets (andpg_ls_*)
От | Fabien COELHO |
---|---|
Тема | Re: pg_ls_tmpdir to show directories and shared filesets (andpg_ls_*) |
Дата | |
Msg-id | alpine.DEB.2.22.394.2006070908120.32228@pseudo обсуждение исходный текст |
Ответ на | Re: pg_ls_tmpdir to show directories and shared filesets (andpg_ls_*) (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: pg_ls_tmpdir to show directories and shared filesets (andpg_ls_*)
|
Список | pgsql-hackers |
Hello Justin, > Rebased onto 7b48f1b490978a8abca61e9a9380f8de2a56f266 and renumbered OIDs. Some feedback about v18, seen as one patch. Patch applies cleanly & compiles. "make check" is okay. pg_stat_file() and pg_stat_dir_files() now return a char type, as well as the function which call them, but the documentation does not seem to say that it is the case. I must admit that I'm not a fan on the argument management of pg_ls_dir_metadata and pg_ls_dir_metadata_1arg and others. I understand that it saves a few lines though, so maybe let it be. There is a comment in pg_ls_dir_files which talks about pg_ls_dir. Could pg_ls_*dir functions C implementations be dropped in favor of a pure SQL implementation, like you did with recurse? If so, ISTM that pg_ls_dir_files() could be significantly simplified by moving its filtering flag to SQL conditions on "type" and others. That could allow not to change the existing function output a keep the "isdir" column defined as "type = 'd'" where it was used previously, if someone complains, but still have the full capability of "ls". That would also allow to drop the "*_1arg" hacks. Basically I'm advocating having 1 or 2 actual C functions, and all other variants managed at the SQL level. -- Fabien.
В списке pgsql-hackers по дате отправления: