Re: Add support for logging the current role

On Thu, Feb 10, 2011 at 06:56:15PM +0900, Itagaki Takahiro wrote:
> On Mon, Feb 7, 2011 at 04:10, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >> I agree that it's logically good design, but we could not accept it
> >> as long as it breaks tools in the real world...
> > If it does, I think it's pretty clear that those tools are themselves
> > broken..
>
> The word "break" was my wrong choice, but your new parameter still
> requires very wide monitors to display SHOW ALL and pg_settings.
> I'd like to solve the issue even though the feature itself is useful.
> One fast and snappy solution might be to set the default value to
> "default", that means the compatible set of columns.
> Other better ideas?

If some tool barfs on a 330-byte GUC value, we might as well have that tool barf
early and often, not just on non-default values.

FWIW, a 330 byte boot_val doesn't seem like a big deal to me. If it were over
_POSIX2_LINE_MAX (2048), that might be another matter.

> Other questions I raised before might be matters of preference.
> I'd like to here about them form third person.
> * name: log_csv_fields vs. csvlog_fields

+1 for csvlog_fields. We have the precedent of syslog_* and that log_* are all
applicable to more than one log destination.

> * when to assign: PGC_POSTMASTER vs. PGC_SIGHUP

+1 for PGC_SIGHUP. PGC_POSTMASTER is mostly for things where we have not
implemented code to instigate the change after startup (usually because the
difficulty/value ratio of doing so is too high). There's no such problem here,
merely the risk that the DBA might not be prepared to deal with a column list
change mid-logfile. If anything, let's have the documentation mention
pg_rotate_logfile() as potentially useful in conjunction.

nm