Re: [HACKERS] For review: Server instrumentation patch

Bruce Momjian <pgman@candle.pha.pa.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');


> 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.

            regards, tom lane