Tom Lane wrote: > 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');
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@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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq