Re: [PATCH v1] pg_ls_tmpdir to show directories
От | Fabien COELHO |
---|---|
Тема | Re: [PATCH v1] pg_ls_tmpdir to show directories |
Дата | |
Msg-id | alpine.DEB.2.21.2001151013200.11730@pseudo обсуждение исходный текст |
Ответ на | Re: [PATCH v1] pg_ls_tmpdir to show directories (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: [PATCH v1] pg_ls_tmpdir to show directories
|
Список | pgsql-hackers |
Hello Justin, About this v4. It applies cleanly. I'm trying to think about how to get rid of the strange structure and hacks, and the arbitrary looking size 2 array. Also the recursion is one step, but I'm not sure why, ISTM it could/should go on always? Maybe the recursive implementation was not such a good idea, if I suggested it is because I did not noticed the "return next" re-entrant stuff, shame on me. Looking at the code, ISTM that relying on a stack/list would be much cleaner and easier to understand. The code could look like: ls_func() if (first_time) initialize description set next directory to visit while (1) if next directory init/push next directory to visit as current read current directory if emty pop/close current directory elif is_a_dir and recursion allowed set next directory to visit else ... return next tuple cleanup The point is to avoid a hack around the directory_fctx array, to have only one place to push/init a new directory (i.e. call AllocateDir and play around with the memory context) instead of two, and to allow deeper recursion if useful. Details : snprintf return is not checked. Maybe it should say why an overflow cannot occur. "bool nulls[3] = { 0,};" -> "bool nulls[3} = { false, false, false };"? -- Fabien.
В списке pgsql-hackers по дате отправления: