Re: color by default - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: color by default
Date
Msg-id CAMkU=1z0Y33QJLx+ra4U-DzB4yAoUeRmMTPQGpStBZwWKfOjRQ@mail.gmail.com
Whole thread Raw
In response to Re: color by default  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Dec 31, 2019 at 8:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.

FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.


I find color massively useful for grep and its variants, where the hit can show up anywhere on the line.  It was also kind of useful for git, especially "git grep", but on my current system git's colorizing seems hopelessly borked, so I had to turn it off.

But I turned PG_COLOR on and played with many commands, and must say I don't really see much of a point.  When most of these command fail, they only generate a few lines of output, and it isn't hard to spot the error message.  When pg_restore goes wrong, you get a lot of messages but colorizing them isn't really helpful.  I don't need 'error' to show up in red in order to know that I have a lot of errors, especially since the lines which do report errors always have 'error' as the 2nd word on the line, where it isn't hard to spot.  If it could distinguish the important errors from unimportant errors, that would be more helpful.  But if it could reliably do that, why print the unimportant ones at all?

It doesn't seem like this is useful enough to have it on by default, and without it being on by default there is no point in having NO_COLOR to turn if off.  There is something to be said for going with the flow, but the "emerging standard" seems like it has quite a bit further to emerge before I think that would be an important reason.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Greatest Common Divisor
Next
From: Robert Haas
Date:
Subject: Re: global / super barriers (for checksums)