Re: [HACKERS] For review: Server instrumentation patch

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > SELECT pg_ls_dir
> > FROM (
> > SELECT pg_ls_dir(t1.setting)
> > FROM (SELECT setting FROM pg_settings
> > WHERE NAME = 'log_directory') AS t1
> > ) AS t2,
> > (SELECT setting FROM pg_settings
> > WHERE NAME = 'log_filename') AS t3
> > WHERE t2.pg_ls_dir LIKE regexp_replace(t3.setting, '%.*', '') ||
> > '%' || regexp_replace(t3.setting, '.*\\.', '.') ;
>
> This is unnecessarily complicated --- use current_setting, eg,
>
> select * from pg_ls_dir(current_setting('log_directory'))
> where pg_ls_dir like
> regexp_replace(current_setting('log_filename'), '%.', '%', 'g');

Nice.

> > I really don't like that pg_stat_file() to returns a record
> > rather than named columns. How do I even access the individual record
> > values?
>
> "select * from ...". See the documentation:
>
> Use it like this:
>
> SELECT *
> FROM pg_stat_file('filename')
> AS s(length int8, atime timestamptz, mtime timestamptz,
> ctime timestamptz, isdir bool);
>
> I suppose as long it's just this one function at stake, we could imagine
> fixing the pg_proc row after-the-fact (later in the initdb sequence).
> Pretty klugy but something nicer could get done in the 8.2 time frame.

Yes, see my earlier email --- we don't even document the return type of
the function, nor does \df show it. This seems too hard to use.

I am worried that if we improve things in 8.2, we would then be changing
the API of the function. Are the other functions returning records usable?
Could we fix it in a way that later improvements would maintain the same
API?

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