On Thu, Feb 10, 2011 at 06:56:15PM +0900, Itagaki Takahiro wrote: > On Mon, Feb 7, 2011 at 04:10, Stephen Frost <sfr...@snowman.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
