Andreas Pflug wrote:
> 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.

Now that I look at it, you could remove pg_file_length() and allow
pg_dir_ls to show you the file sizes.  The only problem is that the
length is needed for the read API so you would need to use a WHERE
clause to pick the file where you want the size, rather than just pass
the file name.

-- 
  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 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to