Re: [HACKERS] For review: Server instrumentation patch

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');

> 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