Re: logfile subprocess and Fancy File Functions - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: logfile subprocess and Fancy File Functions
Date
Msg-id 200407211430.i6LEUNU24970@candle.pha.pa.us
Whole thread Raw
In response to Re: logfile subprocess and Fancy File Functions  (Andreas Pflug <pgadmin@pse-consulting.de>)
Responses Re: logfile subprocess and Fancy File Functions  (Andreas Pflug <pgadmin@pse-consulting.de>)
List pgsql-patches
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Andreas Pflug wrote:
> >
>
> >
> >
> > OK, new idea.  Forget about modifying pg_dir_ls().  Instead add
> > pg_file_stat the returns the file size, times.  You can then easily use
> > that for file size and times.  Also, if you want, add an is_dir boolean
> > so people can write functions that walk the directory tree.
>
> I now replaced pg_logfile_length, instead pg_logfile_stat(text) will
> return a record (len int8, ctime timestamp, atime timestamp, mtime
> timestamp, isdir bool).

You mean pg_file_stat(text), right?  That's what I see in your code.

> For convenience, I'd like to have the function
>
> CREATE FUNCTION pg_file_length(text) RETURNS int8
> AS
> $BODY$
> SELECT len
>    FROM pg_file_stat($1) AS stat
>     (len int8, ctime timestamp,
>     atime timestamp, mtime timestamp, isdir bool)
> $BODY$ LANGUAGE SQL STRICT;
>
> Where is the right place to put it?

Take a look at obj_description in include/catalog/pg_proc.h.  That
should be a good example.

> Also, I wonder how to join pg_file_stat and pg_dir_ls to get a ls -l
> like listing. Apparently I can't do that, unless I don't code pg_dir_ls
> as returning records too, right?

Ideally you want:

    select filename, pg_file_stat(filename)
    from pg_dir_ls()

or something like that.  However, I don't think you can have a function
call returning multiple values in the target list, and I can't figure
out how to pass an argument to the function if it is in the target list.
Ideas?

> > I noticed we had a big logging discussion during 7.4 beta about logging
> > and log rotation.  This patch is clearly superior to the ideas we had at
> > that time.
> >
>
> Currently, the discussion circles around file functions, not logging. If
> you think that part is clean, how about committing it separately so it
> can be tested/used (no problem if pg_logfile_rotate() isn't available
> right from the start). I'll supply docs RSN.

Is pg_logfile_rotate() not working?  You mean pg_file_length().

Seems we should get this stat() idea working first.  Adjusting catalog
entries once they are in CVS means a catalog bump for every catalog
change.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-patches by date:

Previous
From: "David F. Skoll"
Date:
Subject: Re: Patch for pg_dump: Multiple -t options and new -T
Next
From: Tom Lane
Date:
Subject: Re: Patch for pg_dump: Multiple -t options and new -T option