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.2001160927390.30419@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  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
Hello Justin,

>> 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?
>
> Because tmpfiles only go one level deep.

I'm not sure it is a general rule. ISTM that extensions can use tmp files, 
and we would have no control about what they would do there.

>> Looking at the code, ISTM that relying on a stack/list would be much cleaner
>> and easier to understand. The code could look like:
>
> I'm willing to change the implementation, but only after there's an agreement
> about the desired behavior (extra column, one level, etc).

For the level, ISTM that the implementation should not make this 
assumption. If in practice there is just one level, then the function will 
not recurse deep, no problem.

For the column, I'm not sure that "isdir" is necessary.

You could put it implicitely in the file name by ending it with "/", 
and/or showing the directory contents is enough a hint that there is a 
directory?

Also, I'm not fully sure why ".*" files should be skipped, maybe it should 
be an option? Or the user can filter it with SQL if it does not want them?

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: type info support functions for functions that use"any" type
Next
From: Daniel Gustafsson
Date:
Subject: Re: Setting min/max TLS protocol in clientside libpq