Re: [PATCH v1] pg_ls_tmpdir to show directories - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCH v1] pg_ls_tmpdir to show directories
Date
Msg-id alpine.DEB.2.21.1912281555010.24861@pseudo
Whole thread Raw
In response to Re: [PATCH v1] pg_ls_tmpdir to show directories  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: [PATCH v1] pg_ls_tmpdir to show directories
List pgsql-hackers
Hello Justin,

>> Ok, so this suggests recursing into subdirs, which requires to make a
>> separate function of the inner loop.
>
> Yea, it suggests that; but, SRF_RETURN_NEXT doesn't make that very easy.
> It'd need to accept the fcinfo argument, and pg_ls_dir_files would call it once
> for every tuple to be returned.  So it's recursive and saves its state...
>
> The attached is pretty ugly, but I can't see how to do better.

Hmmm… I do agree with pretty ugly:-)

If it really neads to be in the structure, why not save the open directory 
field in the caller and restore it after the recursive call, and pass the 
rest of the structure as a pointer? Something like:

   ... root_function(...)
   {
      struct status_t status = initialization();
      ...
      call rec_function(&status, path)
      ...
      cleanup();
   }

   ... rec_function(struct *status, path)
   {
      status->dir = opendir(path);
      for (dir contents)
      {
         if (it_is_a_dir)
         {
              /* some comment about why we do that… */
              dir_t saved = status->dir;
              status->dir = NULL;
              rec_function(status, subpath);
              status->dir = saved;
         }
      }
     closedir(status->dir), status->dir = NULL;
   }

> The alternative seems to be to build up a full list of pathnames in the SRF
> initial branch, and stat them all later.  Or stat them all in the INITIAL case,
> and keep a list of stat structures to be emited during future calls.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: use CLZ instruction in AllocSetFreeIndex()
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions