Thread: 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
Re: PGCOLOR? (Re: pgsql: Unified logging system for command-lineprograms)
From
Peter Eisentraut
Date:
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
Re: PGCOLOR? (Re: pgsql: Unified logging system for command-line programs)
From
Masahiko Sawada
Date:
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
Re: PGCOLOR? (Re: pgsql: Unified logging system for command-lineprograms)
From
Peter Eisentraut
Date:
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