Andreas Pflug wrote: > > 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.
This patch looks good to me. As far as your question about pg_dir_ls --- you already return multiple columns from pg_logdir_ls, so it seems you would do the same for returning stat() information from pg_dir_ls, right? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
