Обсуждение: PGCOLOR? (Re: pgsql: Unified logging system for command-lineprograms)

Re: Peter Eisentraut 2019-04-01 <E1hB1d6-00051m-1s@gemulon.postgresql.org>
> - Some color in the messages, similar to gcc and clang.  Set
>   PG_COLOR=auto to try it out.  Some colors are predefined, but can be
>   customized by setting PG_COLORS.

Can we rename PG_COLOR to PGCOLOR? This is the only PG* environment
variable prefixed with the extra underscore, and remembering that will
be confusing. (Like pgbench should really be named pg_bench for
consistency.) Even if it's not a libpq variable, but that's an
implementation detail that users shouldn't have to worry about.

From reindexdb(1):

NAME
       reindexdb - reindex a PostgreSQL database

ENVIRONMENT
       PGDATABASE
       PGHOST
       PGPORT
       PGUSER
           Default connection parameters

       PG_COLOR
           Specifies whether to use color in diagnostics messages. Possible values are always, auto, never.

Also, why doesn't this default to 'auto'? Lots of programs have moved
to using colors by default over the last years, including git and gcc.

Christoph

On 2019-04-09 11:22, Christoph Berg wrote:
> Can we rename PG_COLOR to PGCOLOR? This is the only PG* environment
> variable prefixed with the extra underscore, and remembering that will
> be confusing. (Like pgbench should really be named pg_bench for
> consistency.) Even if it's not a libpq variable, but that's an
> implementation detail that users shouldn't have to worry about.

I'm okay with changing it.  As you indicate, I chose the name so that it
doesn't look like a libpq variable.  There are some other PG_ variables
throughout the code, but those appear to be mostly for internal use.
Also, there is GCC_COLORS, LS_COLORS, etc.  But perhaps this wisdom will
be lost on users who just read the man page and get confused. ;-)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Peter Eisentraut 2019-04-09 <d483cdb6-db98-9b2f-7f2b-eed0f4bd975d@2ndquadrant.com>
> I'm okay with changing it.  As you indicate, I chose the name so that it
> doesn't look like a libpq variable.  There are some other PG_ variables
> throughout the code, but those appear to be mostly for internal use.
> Also, there is GCC_COLORS, LS_COLORS, etc.  But perhaps this wisdom will
> be lost on users who just read the man page and get confused. ;-)

Do we need two variables to control this? I was only looking at
PG_COLOR, and noticed PG_COLORS only later. Keeping PG_COLORS aligned
with {GCC,LS}_COLORS makes sense. How about removing PG_COLOR, and
making "auto" the default? (Maybe we could still support "PG_COLORS=off")

Christoph

On Tue, Apr 9, 2019 at 9:01 PM Christoph Berg <myon@debian.org> wrote:
>
> Re: Peter Eisentraut 2019-04-09 <d483cdb6-db98-9b2f-7f2b-eed0f4bd975d@2ndquadrant.com>
> > I'm okay with changing it.  As you indicate, I chose the name so that it
> > doesn't look like a libpq variable.  There are some other PG_ variables
> > throughout the code, but those appear to be mostly for internal use.
> > Also, there is GCC_COLORS, LS_COLORS, etc.  But perhaps this wisdom will
> > be lost on users who just read the man page and get confused. ;-)
>
> Do we need two variables to control this? I was only looking at
> PG_COLOR, and noticed PG_COLORS only later. Keeping PG_COLORS aligned
> with {GCC,LS}_COLORS makes sense. How about removing PG_COLOR, and
> making "auto" the default? (Maybe we could still support "PG_COLORS=off")
>

I think the if we keep two variables user can set the same value to
both GCC_COLORS and PG_COLORS. Rather I think it's a problem that
there is no documentation of PG_COLORS. Thoughts?

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On 2019-06-06 11:08, Masahiko Sawada wrote:
> On Tue, Apr 9, 2019 at 9:01 PM Christoph Berg <myon@debian.org> wrote:
>>
>> Re: Peter Eisentraut 2019-04-09 <d483cdb6-db98-9b2f-7f2b-eed0f4bd975d@2ndquadrant.com>
>>> I'm okay with changing it.  As you indicate, I chose the name so that it
>>> doesn't look like a libpq variable.  There are some other PG_ variables
>>> throughout the code, but those appear to be mostly for internal use.
>>> Also, there is GCC_COLORS, LS_COLORS, etc.  But perhaps this wisdom will
>>> be lost on users who just read the man page and get confused. ;-)
>>
>> Do we need two variables to control this? I was only looking at
>> PG_COLOR, and noticed PG_COLORS only later. Keeping PG_COLORS aligned
>> with {GCC,LS}_COLORS makes sense. How about removing PG_COLOR, and
>> making "auto" the default? (Maybe we could still support "PG_COLORS=off")
>>
> 
> I think the if we keep two variables user can set the same value to
> both GCC_COLORS and PG_COLORS. Rather I think it's a problem that
> there is no documentation of PG_COLORS. Thoughts?

It looks like there is documentation for PG_COLORS in the release notes
now, which seems like an odd place.  Suggestions for a better place?

And any more opinions for PG_COLORS vs PGCOLORS naming?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2019-06-06 11:08, Masahiko Sawada wrote:
>>> Do we need two variables to control this? I was only looking at
>>> PG_COLOR, and noticed PG_COLORS only later. Keeping PG_COLORS aligned
>>> with {GCC,LS}_COLORS makes sense. How about removing PG_COLOR, and
>>> making "auto" the default? (Maybe we could still support "PG_COLORS=off")

>> I think the if we keep two variables user can set the same value to
>> both GCC_COLORS and PG_COLORS. Rather I think it's a problem that
>> there is no documentation of PG_COLORS. Thoughts?

> It looks like there is documentation for PG_COLORS in the release notes
> now, which seems like an odd place.  Suggestions for a better place?

I stuck that in because Bruce's text didn't make any sense to me,
so I went and read the code to see what it was actually doing.
I didn't know that it hadn't been correctly documented in the first
place ;-)

I'm not for forcing "auto" mode all the time; that will surely break
things for some people.  So I think the behavior is fine and
we should just fix the docs.  (Possibly my opinion is biased here
by the fact that I hate all forms of colorized output with a deep,
abiding passion, as Robert would put it.  So off-by-default is just
fine with me.)

> And any more opinions for PG_COLORS vs PGCOLORS naming?

Following the precedent of LS_COLORS makes sense from here.

            regards, tom lane

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> It looks like there is documentation for PG_COLORS in the release notes
> now, which seems like an odd place.  Suggestions for a better place?

BTW, as far as that goes, it looks like PG_COLOR is documented separately
in each frontend program's "Environment" man page section.  That's a bit
duplicative but I don't think we have a better answer right now.  Seems
like you just need to add boilerplate text about PG_COLORS alongside
each of those.

            regards, tom lane