Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

On 12/23/20 2:27 PM, Stephen Frost wrote:
> * Justin Pryzby (pryzby(at)telsasoft(dot)com) wrote:
>> On Mon, Nov 23, 2020 at 04:14:18PM -0500, Tom Lane wrote:
>>> * I don't think it's okay to change the existing signatures of
>>> pg_ls_logdir() et al. Even if you can make an argument that it's
>>> not too harmful to add more output columns, replacing pg_stat_file's
>>> isdir output with something of a different name and datatype is most
>>> surely not OK --- there is no possible way that doesn't break existing
>>> user queries.
>>>
>>> I think possibly a more acceptable approach is to leave these functions
>>> alone but add documentation explaining how to get the additional info.
>>> You could say things along the lines of "pg_ls_waldir() is the same as
>>> pg_ls_dir_metadata('pg_wal') except for showing fewer columns."
>>
>> On Mon, Nov 23, 2020 at 06:06:19PM -0500, Tom Lane wrote:
>>> I'm mostly concerned about removing the isdir output of pg_stat_file().
>>> Maybe we could compromise to the extent of keeping that, allowing it
>>> to be partially duplicative of a file-type-code output column.
>>
>> On Tue, Nov 24, 2020 at 11:53:22AM -0500, Stephen Frost wrote:
>>> I don't have any particular issue with keeping isdir as a convenience
>>> column. I agree it'll now be a bit duplicative but that seems alright.
>>
>> Maybe we should do what Tom said, and leave pg_ls_* unchanged, but also mark
>> them as deprecated in favour of:
>> | pg_ls_dir_metadata(dir), dir={'pg_wal/archive_status', 'log', 'pg_wal', 'base/pgsql_tmp'}
>
> Haven't really time to review the patches here in detail right now
> (maybe next month), but in general, I dislike marking things as
> deprecated.
Stephen, are you still planning to review these patches?

Regards,
--
-David
david(at)pgmasters(dot)net