Re: Patch to implement pg_current_logfile() function - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: Patch to implement pg_current_logfile() function
Date
Msg-id 20161014165007.bzbuzeklsvcr3swh@msg.df7cb.de
Whole thread Raw
In response to Re: Patch to implement pg_current_logfile() function  (Christoph Berg <myon@debian.org>)
Responses Re: Patch to implement pg_current_logfile() function  (Gilles Darold <gilles.darold@dalibo.com>)
List pgsql-hackers
Re: To Gilles Darold 2016-10-14 <20161014125406.albrfj3qldiwjnrr@msg.df7cb.de>
> A better design might be to return two columns instead:
> 
> postgres=# select * from pg_current_logfile();
>              stderr                    |              csvlog
> ---------------------------------------+---------------------------------------
>  pg_log/postgresql-2016-10-07_1646.log | pg_log/postgresql-2016-10-07_1646.csv

> (The alternative could be to return an extra column:
> 
> postgres=# select * from pg_current_logfile();
>   type  |     logfile
> ---------------------------------------
>  stderr | pg_log/postgresql-2016-10-07_1646.log
>  csvlog | pg_log/postgresql-2016-10-07_1646.csv

Usability-wise it might be better to have pg_current_logfile() just
return the name of the text log (and possibly a HINT that there's a
csv log if stderr is disabled), and have a second function
pg_current_csvlog() return the csv log name.

The choice which design is better will probably depend on if we think
these functions are meant for interactive use (-> 2 functions), or for
automated use (-> 2 columns). My guess would be that interactive use
is more important here.

Christoph



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.
Next
From: Tom Lane
Date:
Subject: Re: tablesample test failure with small TOAST_TUPLE_THRESHOLD