Re: logfile subprocess and Fancy File Functions

Peter Eisentraut wrote:
> Bruce Momjian wrote:
>
>>For logs I think pgsql_ is best because that filename is already
>>going to be long, and I don't usually like dashes in file names.
>>They look too much like arguments, but tarballs use them and it looks
>>OK there, I guess.
>
>
> I wasn't talking about what looks best, I was talking about current
> practice for log files. From that you might be able to extrapolate
> what other people have previously found to look best.
>
> In any case, we're not using DOS and 12 inch monitors any more. File
> names can be as long as we want.
>

Before the thread concentrates too much on a decent default value, I'm
posting a fresh version of the patch, for some more discussion. Current
default for pg_logfile_prefix is 'postgresql-', may the committers
decide which name is The Perfect One.

All previous suggestions have been included, (nb: abstimein is not
usable, because it ereports(ERROR) on failure; we want to skip wrong
files gracefully, so I'm using ParseDateTime and DecodeDateTime instead).

I'd still need feedback on pg_dir_ls: should it merely return a setof
text, or should I enrich it to a record returning all stat data? After
spending another thought on it, I believe the more sql-like approach is
to deliver a full-featured record which is selected for the desired
data, not adding columns with functions.

Regards,
Andreas