pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedcolor by default
34+ messages / 15 participants
[nested] [flat]
* color by default
@ 2019-12-31 10:40 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 2 replies; 34+ messages in thread
From: Peter Eisentraut @ 2019-12-31 10:40 UTC (permalink / raw)
To: pgsql-hackers
With the attached patch, I propose to enable the colored output by
default in PG13.
For those who don't like color output, I also add support for the
environment variable NO_COLOR, which is an emerging standard for turning
off color across different software packages (https://no-color.org/).
Of course, you can also continue to use the PG_COLOR variable.
I have looked around how other packages do the automatic color
detection. It's usually a combination of mysterious termcap stuff and
slightly less mysterious matching of the TERM variable against a list of
known terminal types. I figured we can skip the termcap stuff and still
get really good coverage in practice, so that's what I did.
I have also added a documentation appendix to explain all of this.
(Perhaps we should now remove the repetitive mention of the PG_COLOR
variable in each man page, but I haven't done that in this patch.)
I'm aware of the pending patch to improve color support on Windows.
I'll check that one out as well, but it appears to be orthogonal to this
one.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 58ca7359728959ccc9d7e96d6fbeb324714e9317 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Tue, 31 Dec 2019 11:20:21 +0100
Subject: [PATCH] Use colors by default
Refine the system by which it is decided whether colored output it
used. Besides the PG_COLOR environment variable previously in use, we
now also observe the NO_COLORS environment variable. Furthermore, if
neither of these are set, we check whether the terminal supports
colors using the TERM environment variable and use colors
automatically if so.
Also add a documentation appendix that explains who this works and how
the individual colors can be configured.
---
doc/src/sgml/color.sgml | 102 +++++++++++++++++++++++++++++++++++++
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/postgres.sgml | 1 +
src/common/logging.c | 41 +++++++++++++++
4 files changed, 145 insertions(+)
create mode 100644 doc/src/sgml/color.sgml
diff --git a/doc/src/sgml/color.sgml b/doc/src/sgml/color.sgml
new file mode 100644
index 0000000000..f1697230e5
--- /dev/null
+++ b/doc/src/sgml/color.sgml
@@ -0,0 +1,102 @@
+<!-- doc/src/sgml/color.sgml -->
+
+<appendix id="color">
+ <title>Color Support</title>
+
+ <indexterm zone="color">
+ <primary>color</primary>
+ </indexterm>
+
+ <para>
+ Most programs in the PostgreSQL package can produce colorized console
+ output. This appendix describes how that is configured.
+ </para>
+
+ <sect1 id="color-when">
+ <title>When Color is Used</title>
+
+ <para>
+ The decision whether to use colorized output is made according to the
+ following procedure:
+
+ <orderedlist>
+ <listitem>
+ <para>
+ If the environment variable
+ <envar>PG_COLOR</envar><indexterm><primary>PG_COLOR</primary></indexterm>
+ is set:
+ </para>
+
+ <orderedlist>
+ <listitem>
+ <para>
+ If the value is <literal>always</literal>, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the value is <literal>auto</literal> and the standard error stream
+ is associated with a terminal device, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Otherwise, color is not used.
+ </para>
+ </listitem>
+ </orderedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the environment variable <envar>NO_COLOR</envar> is set, then color
+ is not used. See <ulink url="https://no-color.org/"/; for more
+ information about this.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the environment variable <envar>TERM</envar> is set to a terminal
+ type that is recognized to support color and the standard error stream
+ is associated with a terminal device, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Otherwise, color is not used.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ </sect1>
+
+ <sect1 id="color-which">
+ <title>Configuring the Colors</title>
+
+ <para>
+ The actual colors to be used are configured using the environment variable
+ <envar>PG_COLORS</envar><indexterm><primary>PG_COLORS</primary></indexterm>
+ (note plural). The value is a colon-separated list of
+ <literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal>
+ pairs. The keys specify what the color is to be used for. The values are
+ SGR (Select Graphic Rendition) specifications, which are interpreted by the
+ terminal.
+ </para>
+
+ <para>
+ The default value is <literal>error=01;31:warning=01;35:locus=01</literal>.
+ </para>
+
+ <tip>
+ <para>
+ This color specification format is also used by other software packages
+ such as <productname>GCC</productname>, <productname>GNU
+ coreutils</productname>, and <productname>GNU grep</productname>.
+ </para>
+ </tip>
+ </sect1>
+</appendix>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 3da2365ea9..1043d0f7ab 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -170,6 +170,7 @@
<!ENTITY limits SYSTEM "limits.sgml">
<!ENTITY acronyms SYSTEM "acronyms.sgml">
+<!ENTITY color SYSTEM "color.sgml">
<!ENTITY features-supported SYSTEM "features-supported.sgml">
<!ENTITY features-unsupported SYSTEM "features-unsupported.sgml">
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index e59cba7997..1f7bd32878 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -278,6 +278,7 @@ <title>Appendixes</title>
&docguide;
&limits;
&acronyms;
+ &color;
</part>
diff --git a/src/common/logging.c b/src/common/logging.c
index 895da7150e..9b0c67046f 100644
--- a/src/common/logging.c
+++ b/src/common/logging.c
@@ -32,6 +32,37 @@ static const char *sgr_locus = NULL;
#define ANSI_ESCAPE_FMT "\x1b[%sm"
#define ANSI_ESCAPE_RESET "\x1b[0m"
+
+#define str_starts_with(str, substr) (strncmp(str, substr, strlen(substr)) == 0)
+#define str_ends_with(str, substr) (strcmp(str + strlen(str) - strlen(substr), substr) == 0)
+
+static bool
+terminal_supports_color(void)
+{
+ const char *term_env = getenv("TERM");
+
+ if (!term_env)
+ return false;
+ else if (strcmp(term_env, "ansi") == 0)
+ return true;
+ else if (strcmp(term_env, "cygwin") == 0)
+ return true;
+ else if (strcmp(term_env, "linux") == 0)
+ return true;
+ else if (str_starts_with(term_env, "rxvt"))
+ return true;
+ else if (str_starts_with(term_env, "screen"))
+ return true;
+ else if (str_starts_with(term_env, "xterm"))
+ return true;
+ else if (str_starts_with(term_env, "vt100"))
+ return true;
+ else if (str_ends_with(term_env, "color"))
+ return true;
+ else
+ return false;
+}
+
/*
* This should be called before any output happens.
*/
@@ -53,6 +84,16 @@ pg_logging_init(const char *argv0)
(strcmp(pg_color_env, "auto") == 0 && isatty(fileno(stderr))))
log_color = true;
}
+ else if (getenv("NO_COLOR"))
+ {
+ /* see https://no-color.org/ */
+ log_color = false;
+ }
+ else
+ {
+ log_color = isatty(fileno(stderr)) &&
+ terminal_supports_color();
+ }
if (log_color)
{
--
2.24.1
Attachments:
[text/plain] 0001-Use-colors-by-default.patch (6.1K, ../../bbdcce43-bd2e-5599-641b-9b44b9e0add4@2ndquadrant.com/2-0001-Use-colors-by-default.patch)
download | inline diff:
From 58ca7359728959ccc9d7e96d6fbeb324714e9317 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Tue, 31 Dec 2019 11:20:21 +0100
Subject: [PATCH] Use colors by default
Refine the system by which it is decided whether colored output it
used. Besides the PG_COLOR environment variable previously in use, we
now also observe the NO_COLORS environment variable. Furthermore, if
neither of these are set, we check whether the terminal supports
colors using the TERM environment variable and use colors
automatically if so.
Also add a documentation appendix that explains who this works and how
the individual colors can be configured.
---
doc/src/sgml/color.sgml | 102 +++++++++++++++++++++++++++++++++++++
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/postgres.sgml | 1 +
src/common/logging.c | 41 +++++++++++++++
4 files changed, 145 insertions(+)
create mode 100644 doc/src/sgml/color.sgml
diff --git a/doc/src/sgml/color.sgml b/doc/src/sgml/color.sgml
new file mode 100644
index 0000000000..f1697230e5
--- /dev/null
+++ b/doc/src/sgml/color.sgml
@@ -0,0 +1,102 @@
+<!-- doc/src/sgml/color.sgml -->
+
+<appendix id="color">
+ <title>Color Support</title>
+
+ <indexterm zone="color">
+ <primary>color</primary>
+ </indexterm>
+
+ <para>
+ Most programs in the PostgreSQL package can produce colorized console
+ output. This appendix describes how that is configured.
+ </para>
+
+ <sect1 id="color-when">
+ <title>When Color is Used</title>
+
+ <para>
+ The decision whether to use colorized output is made according to the
+ following procedure:
+
+ <orderedlist>
+ <listitem>
+ <para>
+ If the environment variable
+ <envar>PG_COLOR</envar><indexterm><primary>PG_COLOR</primary></indexterm>
+ is set:
+ </para>
+
+ <orderedlist>
+ <listitem>
+ <para>
+ If the value is <literal>always</literal>, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the value is <literal>auto</literal> and the standard error stream
+ is associated with a terminal device, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Otherwise, color is not used.
+ </para>
+ </listitem>
+ </orderedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the environment variable <envar>NO_COLOR</envar> is set, then color
+ is not used. See <ulink url="https://no-color.org/"/> for more
+ information about this.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the environment variable <envar>TERM</envar> is set to a terminal
+ type that is recognized to support color and the standard error stream
+ is associated with a terminal device, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Otherwise, color is not used.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ </sect1>
+
+ <sect1 id="color-which">
+ <title>Configuring the Colors</title>
+
+ <para>
+ The actual colors to be used are configured using the environment variable
+ <envar>PG_COLORS</envar><indexterm><primary>PG_COLORS</primary></indexterm>
+ (note plural). The value is a colon-separated list of
+ <literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal>
+ pairs. The keys specify what the color is to be used for. The values are
+ SGR (Select Graphic Rendition) specifications, which are interpreted by the
+ terminal.
+ </para>
+
+ <para>
+ The default value is <literal>error=01;31:warning=01;35:locus=01</literal>.
+ </para>
+
+ <tip>
+ <para>
+ This color specification format is also used by other software packages
+ such as <productname>GCC</productname>, <productname>GNU
+ coreutils</productname>, and <productname>GNU grep</productname>.
+ </para>
+ </tip>
+ </sect1>
+</appendix>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 3da2365ea9..1043d0f7ab 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -170,6 +170,7 @@
<!ENTITY limits SYSTEM "limits.sgml">
<!ENTITY acronyms SYSTEM "acronyms.sgml">
+<!ENTITY color SYSTEM "color.sgml">
<!ENTITY features-supported SYSTEM "features-supported.sgml">
<!ENTITY features-unsupported SYSTEM "features-unsupported.sgml">
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index e59cba7997..1f7bd32878 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -278,6 +278,7 @@ <title>Appendixes</title>
&docguide;
&limits;
&acronyms;
+ &color;
</part>
diff --git a/src/common/logging.c b/src/common/logging.c
index 895da7150e..9b0c67046f 100644
--- a/src/common/logging.c
+++ b/src/common/logging.c
@@ -32,6 +32,37 @@ static const char *sgr_locus = NULL;
#define ANSI_ESCAPE_FMT "\x1b[%sm"
#define ANSI_ESCAPE_RESET "\x1b[0m"
+
+#define str_starts_with(str, substr) (strncmp(str, substr, strlen(substr)) == 0)
+#define str_ends_with(str, substr) (strcmp(str + strlen(str) - strlen(substr), substr) == 0)
+
+static bool
+terminal_supports_color(void)
+{
+ const char *term_env = getenv("TERM");
+
+ if (!term_env)
+ return false;
+ else if (strcmp(term_env, "ansi") == 0)
+ return true;
+ else if (strcmp(term_env, "cygwin") == 0)
+ return true;
+ else if (strcmp(term_env, "linux") == 0)
+ return true;
+ else if (str_starts_with(term_env, "rxvt"))
+ return true;
+ else if (str_starts_with(term_env, "screen"))
+ return true;
+ else if (str_starts_with(term_env, "xterm"))
+ return true;
+ else if (str_starts_with(term_env, "vt100"))
+ return true;
+ else if (str_ends_with(term_env, "color"))
+ return true;
+ else
+ return false;
+}
+
/*
* This should be called before any output happens.
*/
@@ -53,6 +84,16 @@ pg_logging_init(const char *argv0)
(strcmp(pg_color_env, "auto") == 0 && isatty(fileno(stderr))))
log_color = true;
}
+ else if (getenv("NO_COLOR"))
+ {
+ /* see https://no-color.org/ */
+ log_color = false;
+ }
+ else
+ {
+ log_color = isatty(fileno(stderr)) &&
+ terminal_supports_color();
+ }
if (log_color)
{
--
2.24.1
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2019-12-31 12:13 Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 0 replies; 34+ messages in thread
From: Juan José Santamaría Flecha @ 2019-12-31 12:13 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers
On Tue, Dec 31, 2019 at 11:40 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:
>
> I'm aware of the pending patch to improve color support on Windows.
> I'll check that one out as well, but it appears to be orthogonal to this
> one.
>
>
Actually I think it would be better to rebase that patch on top of this, as
the Windows function enable_vt_mode() incorporates the logic of both
isatty() and terminal_supports_color() by enabling CMDs support of VT100
escape codes.
Regards,
Juan José Santamaría Flecha
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2019-12-31 13:35 Tom Lane <tgl@sss.pgh.pa.us>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 7 replies; 34+ messages in thread
From: Tom Lane @ 2019-12-31 13:35 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers
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 may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
regards, tom lane
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2019-12-31 13:52 Abel Abraham Camarillo Ojeda <acamari@verlet.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 0 replies; 34+ messages in thread
From: Abel Abraham Camarillo Ojeda @ 2019-12-31 13:52 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Tue, Dec 31, 2019 at 7: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 may well be in the minority, but I think some kind of straw poll
> might be advisable, rather than doing this just because.
>
+1
> regards, tom lane
>
>
>
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2019-12-31 13:59 Daniel Gustafsson <daniel@yesql.se>
parent: Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 0 replies; 34+ messages in thread
From: Daniel Gustafsson @ 2019-12-31 13:59 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
> On 31 Dec 2019, at 14:35, 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.
Me too.
> I may well be in the minority, but I think some kind of straw poll
> might be advisable, rather than doing this just because.
+1
cheers ./daniel
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2019-12-31 14:12 Andreas Joseph Krogh <andreas@visena.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 1 reply; 34+ messages in thread
From: Andreas Joseph Krogh @ 2019-12-31 14:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
På tirsdag 31. desember 2019 kl. 14:35:39, skrev Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>>:
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 may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
It's easier to spot errors/warnings when they are colored/emphasized imo. Much
like colored output from grep/diff; We humans have colored vision for a reason.
--
Andreas Joseph Krogh
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2019-12-31 15:18 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Andreas Joseph Krogh <andreas@visena.com>
0 siblings, 1 reply; 34+ messages in thread
From: Alvaro Herrera @ 2019-12-31 15:18 UTC (permalink / raw)
To: Andreas Joseph Krogh <andreas@visena.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On 2019-Dec-31, Andreas Joseph Krogh wrote:
> It's easier to spot errors/warnings when they are colored/emphasized imo. Much
> like colored output from grep/diff; We humans have colored vision for a reason.
I do use color output (and find it useful), for that reason.
I'm not sure that the documentation addition properly describes the
logic to be used; if it does, I'm not sure that the logic is really what
we want. Is the logic in the docs supposed to be "last rule that
matches wins" or "first rule that matches wins"? I think that should be
explicit. Do we want to have NO_COLORS override the TERM heuristics?
(I'm pretty sure we do.) OTOH we also want PG_COLORS to override
NO_COLORS.
Per https://no-colors.org (thanks for the link) it seems pretty clear
that people who don't want colors should be already setting NO_COLORS,
and everyone would be happy. It's not just PG programs that are
colorizing stuff.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2019-12-31 15:46 Isaac Morland <isaac.morland@gmail.com>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 0 replies; 34+ messages in thread
From: Isaac Morland @ 2019-12-31 15:46 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Andreas Joseph Krogh <andreas@visena.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Tue, 31 Dec 2019 at 10:18, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
Per https://no-colors.org (thanks for the link) it seems pretty clear
>
https://no-color.org
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2019-12-31 17:32 Jose Luis Tallon <jltallon@adv-solutions.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 0 replies; 34+ messages in thread
From: Jose Luis Tallon @ 2019-12-31 17:32 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
On 31/12/19 14:35, Tom Lane 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 may well be in the minority, but I think some kind of straw poll
> might be advisable, rather than doing this just because.
+1
...and Happy New Year!
/ J.L.
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-01-02 23:38 Gavin Flower <GavinFlower@archidevsys.co.nz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 1 reply; 34+ messages in thread
From: Gavin Flower @ 2020-01-02 23:38 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers
On 01/01/2020 02:35, Tom Lane 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 may well be in the minority, but I think some kind of straw poll
> might be advisable, rather than doing this just because.
>
> regards, tom lane
>
>
I find coloured output very difficult to read, as the colours seem to be
chosen on the basis everyone uses white as the background colour for
terminals -- whereas I use black, as do a lot of other people.
Cheers,
Gavin
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-01-03 18:10 Robert Haas <robertmhaas@gmail.com>
parent: Gavin Flower <GavinFlower@archidevsys.co.nz>
0 siblings, 1 reply; 34+ messages in thread
From: Robert Haas @ 2020-01-03 18:10 UTC (permalink / raw)
To: Gavin Flower <GavinFlower@archidevsys.co.nz>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:
> I find coloured output very difficult to read, as the colours seem to be
> chosen on the basis everyone uses white as the background colour for
> terminals -- whereas I use black, as do a lot of other people.
I don't like colored output either.
(It is, however, probably not a surprise to anyone that I am
old-school in many regards, so how much my opinion ought to count is
debatable. I still use \pset linestyle old-ascii when I remember to
set it, use vi to edit, with hjkl rather than arrow keys, and almost
always prefer a CLI to a GUI when I have the option. I have conceded
the utility of indoor heat and plumbing, though, so maybe there's hope
for me yet.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-01-03 20:25 Jeff Janes <jeff.janes@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 0 replies; 34+ messages in thread
From: Jeff Janes @ 2020-01-03 20:25 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; 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
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-01-06 05:38 Michael Paquier <michael@paquier.xyz>
parent: Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 34+ messages in thread
From: Michael Paquier @ 2020-01-06 05:38 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Gavin Flower <GavinFlower@archidevsys.co.nz>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Fri, Jan 03, 2020 at 01:10:30PM -0500, Robert Haas wrote:
> On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower
> <GavinFlower@archidevsys.co.nz> wrote:
>> I find coloured output very difficult to read, as the colours seem to be
>> chosen on the basis everyone uses white as the background colour for
>> terminals -- whereas I use black, as do a lot of other people.
>
> I don't like colored output either.
I don't like colored output either. However there is an easy way to
disable that so applying this patch does not change things IMO as
anybody unhappy with colors can just disable it with a one-liner in
a bashrc or such.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20200106053824.GO3598@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-01-06 07:26 Gavin Flower <GavinFlower@archidevsys.co.nz>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 34+ messages in thread
From: Gavin Flower @ 2020-01-06 07:26 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Robert Haas <robertmhaas@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On 06/01/2020 18:38, Michael Paquier wrote:
> On Fri, Jan 03, 2020 at 01:10:30PM -0500, Robert Haas wrote:
>> On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower
>> <GavinFlower@archidevsys.co.nz> wrote:
>>> I find coloured output very difficult to read, as the colours seem to be
>>> chosen on the basis everyone uses white as the background colour for
>>> terminals -- whereas I use black, as do a lot of other people.
>> I don't like colored output either.
> I don't like colored output either. However there is an easy way to
> disable that so applying this patch does not change things IMO as
> anybody unhappy with colors can just disable it with a one-liner in
> a bashrc or such.
> --
> Michael
That's kind of like using a sledgehammer to crack a nut.
The colour in grep output is often useful.
I'd like to control it per application.
Cheers,
Gavin
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-02 12:00 Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
parent: Gavin Flower <GavinFlower@archidevsys.co.nz>
0 siblings, 1 reply; 34+ messages in thread
From: Juan José Santamaría Flecha @ 2020-03-02 12:00 UTC (permalink / raw)
To: Gavin Flower <GavinFlower@archidevsys.co.nz>; +Cc: Michael Paquier <michael@paquier.xyz>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
The patch to improve color support on Windows has been commited [1], and I
would like to share some of the discussion there that might affect this
patch.
- The documentation/comments could make a better job of explaining the case
of PG_COLOR equals 'always', explicitly saying that no checks are done
about the output channel.
Aside from the decision about what the default coloring behaviour should
be, there are parts of this patch that could be applied independently, as
an improvement on the current state.
- The new function terminal_supports_color() should also apply when
PG_COLOR is 'auto', to minimize the chances of seeing escape characters in
the user terminal.
- The new entry in the documentation, specially as the PG_COLORS parameter
seems to be currently undocumented. The programs that can use PG_COLOR
would benefit from getting a link to it.
[1]
https://www.postgresql.org/message-id/20200302064842.GE32059%40paquier.xyz
Regards,
Juan José Santamaría Flecha
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-03 05:31 Michael Paquier <michael@paquier.xyz>
parent: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
0 siblings, 1 reply; 34+ messages in thread
From: Michael Paquier @ 2020-03-03 05:31 UTC (permalink / raw)
To: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; +Cc: Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote:
> - The new entry in the documentation, specially as the PG_COLORS parameter
> seems to be currently undocumented. The programs that can use PG_COLOR
> would benefit from getting a link to it.
The actual problem here is that we don't have an actual centralized
place where we could put that stuff. And anything able to use this
option is basically anything using src/common/logging.c.
Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we
have no actual example of how to use it, and the original thread has
zero reference to it:
https://www.postgresql.org/message-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
And in fact, it took me a while to figure out that using it is a mix
of three keywords ("error", "warning" or "locus") separated by colons
which need to have an equal sign to the color defined. Here is for
example how to make the locus show up in yellow with errors in blue:
export PG_COLORS='error=01;34:locus=01;33'
Having to dig into the code to find out that stuff is not a good user
experience. And I found out about that only because I worked on a
patch touching this area yesterday.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20200303053101.GH32059@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-20 02:15 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 34+ messages in thread
From: Bruce Momjian @ 2020-03-20 02:15 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote:
> On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote:
> > - The new entry in the documentation, specially as the PG_COLORS parameter
> > seems to be currently undocumented. The programs that can use PG_COLOR
> > would benefit from getting a link to it.
>
> The actual problem here is that we don't have an actual centralized
> place where we could put that stuff. And anything able to use this
> option is basically anything using src/common/logging.c.
>
> Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we
> have no actual example of how to use it, and the original thread has
> zero reference to it:
> https://www.postgresql.org/message-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
>
> And in fact, it took me a while to figure out that using it is a mix
> of three keywords ("error", "warning" or "locus") separated by colons
> which need to have an equal sign to the color defined. Here is for
> example how to make the locus show up in yellow with errors in blue:
> export PG_COLORS='error=01;34:locus=01;33'
>
> Having to dig into the code to find out that stuff is not a good user
> experience. And I found out about that only because I worked on a
> patch touching this area yesterday.
I can confirm there is still no mention of PG_COLORS in our
documentation.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-21 02:55 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 34+ messages in thread
From: Bruce Momjian @ 2020-03-21 02:55 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Thu, Mar 19, 2020 at 10:15:57PM -0400, Bruce Momjian wrote:
> On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote:
> > On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote:
> > > - The new entry in the documentation, specially as the PG_COLORS parameter
> > > seems to be currently undocumented. The programs that can use PG_COLOR
> > > would benefit from getting a link to it.
> >
> > The actual problem here is that we don't have an actual centralized
> > place where we could put that stuff. And anything able to use this
> > option is basically anything using src/common/logging.c.
> >
> > Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we
> > have no actual example of how to use it, and the original thread has
> > zero reference to it:
> > https://www.postgresql.org/message-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
> >
> > And in fact, it took me a while to figure out that using it is a mix
> > of three keywords ("error", "warning" or "locus") separated by colons
> > which need to have an equal sign to the color defined. Here is for
> > example how to make the locus show up in yellow with errors in blue:
> > export PG_COLORS='error=01;34:locus=01;33'
> >
> > Having to dig into the code to find out that stuff is not a good user
> > experience. And I found out about that only because I worked on a
> > patch touching this area yesterday.
>
> I can confirm there is still no mention of PG_COLORS in our
> documentation.
My mistake, PG_COLOR (not PG_COLORS) is documented properly.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-21 03:15 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 34+ messages in thread
From: Tom Lane @ 2020-03-21 03:15 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
>> I can confirm there is still no mention of PG_COLORS in our
>> documentation.
> My mistake, PG_COLOR (not PG_COLORS) is documented properly.
Yeah, but the point is precisely that pg_logging_init()
also responds to PG_COLORS, which is not documented anywhere.
regards, tom lane
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-21 03:22 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 34+ messages in thread
From: Bruce Momjian @ 2020-03-21 03:22 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> >> I can confirm there is still no mention of PG_COLORS in our
> >> documentation.
>
> > My mistake, PG_COLOR (not PG_COLORS) is documented properly.
>
> Yeah, but the point is precisely that pg_logging_init()
> also responds to PG_COLORS, which is not documented anywhere.
Oh, I thought it was a typo. OK, so it still an open item.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-21 04:25 Jonah H. Harris <jonah.harris@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 1 reply; 34+ messages in thread
From: Jonah H. Harris @ 2020-03-21 04:25 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; 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.
>
Same.
> I may well be in the minority, but I think some kind of straw poll
> might be advisable, rather than doing this just because.
>
+1 on no color by default.
--
Jonah H. Harris
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-21 13:30 Isaac Morland <isaac.morland@gmail.com>
parent: Jonah H. Harris <jonah.harris@gmail.com>
0 siblings, 0 replies; 34+ messages in thread
From: Isaac Morland @ 2020-03-21 13:30 UTC (permalink / raw)
To: Jonah H. Harris <jonah.harris@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Sat, 21 Mar 2020 at 00:25, Jonah H. Harris <jonah.harris@gmail.com>
wrote:
> 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.
>>
>
> Same.
>
For me it depends on what the colour is doing. I was very pleased when I
first saw coloured output from ls, which if I remember correctly repeats
the information provided by -F but more prominently. Similarly, I
appreciate diff output that highlights the differences. At the same time I
can appreciate a preference for "just plain text please".
> I may well be in the minority, but I think some kind of straw poll
>> might be advisable, rather than doing this just because.
>>
>
> +1 on no color by default.
>
Given that there is apparently a standard NO_COLOR environment variable
which can be set, I think it's reasonable to default to gentle use of
colour, but turn it off if the standard variable is set. Somebody who wants
no color will probably already have the variable set, so in effect for the
people who want it that way no colour would already be the default (not the
default default, but the de facto default).
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-23 05:04 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 34+ messages in thread
From: Michael Paquier @ 2020-03-23 05:04 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Fri, Mar 20, 2020 at 11:22:07PM -0400, Bruce Momjian wrote:
> On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote:
>> Yeah, but the point is precisely that pg_logging_init()
>> also responds to PG_COLORS, which is not documented anywhere.
>
> Oh, I thought it was a typo. OK, so it still an open item.
Yes, I really think that we should have a new section in the docs for
that with more meaningful examples rather than copy-paste that stuff
across more pages of the docs. Note that 5aaa584 has plugged all the
holes related to PG_COLOR I could find, and that pg_ctl and pg_upgrade
initialize logging with pg_logging_init() but these two cannot use
coloring because they have their own idea of what logging should be.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20200323050410.GE2900@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-23 08:32 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 2 replies; 34+ messages in thread
From: Peter Eisentraut @ 2020-03-23 08:32 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On 2020-03-23 06:04, Michael Paquier wrote:
> On Fri, Mar 20, 2020 at 11:22:07PM -0400, Bruce Momjian wrote:
>> On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote:
>>> Yeah, but the point is precisely that pg_logging_init()
>>> also responds to PG_COLORS, which is not documented anywhere.
>>
>> Oh, I thought it was a typo. OK, so it still an open item.
>
> Yes, I really think that we should have a new section in the docs for
> that with more meaningful examples rather than copy-paste that stuff
> across more pages of the docs. Note that 5aaa584 has plugged all the
> holes related to PG_COLOR I could find, and that pg_ctl and pg_upgrade
> initialize logging with pg_logging_init() but these two cannot use
> coloring because they have their own idea of what logging should be.
I'm giving up on making color the default, since there is clearly no
consensus.
Attached is the documentation patch reworked.
Should we delete all the repetitive mentions on the man pages?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 7164d4196ace14a1acc9077a7a4d32e57131ff6e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Mon, 23 Mar 2020 09:22:50 +0100
Subject: [PATCH v2] Document color support
Add a documentation appendix that explains the PG_COLOR and PG_COLORS
environment variables.
---
doc/src/sgml/color.sgml | 71 ++++++++++++++++++++++++++++++++++++++
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/postgres.sgml | 1 +
3 files changed, 73 insertions(+)
create mode 100644 doc/src/sgml/color.sgml
diff --git a/doc/src/sgml/color.sgml b/doc/src/sgml/color.sgml
new file mode 100644
index 0000000000..c30b1942a5
--- /dev/null
+++ b/doc/src/sgml/color.sgml
@@ -0,0 +1,71 @@
+<!-- doc/src/sgml/color.sgml -->
+
+<appendix id="color">
+ <title>Color Support</title>
+
+ <indexterm zone="color">
+ <primary>color</primary>
+ </indexterm>
+
+ <para>
+ Most programs in the PostgreSQL package can produce colorized console
+ output. This appendix describes how that is configured.
+ </para>
+
+ <sect1 id="color-when">
+ <title>When Color is Used</title>
+
+ <para>
+ To use colorized output, set the environment variable
+ <envar>PG_COLOR</envar><indexterm><primary>PG_COLOR</primary></indexterm>
+ as follows:
+
+ <orderedlist>
+ <listitem>
+ <para>
+ If the value is <literal>always</literal>, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the value is <literal>auto</literal> and the standard error stream
+ is associated with a terminal device, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Otherwise, color is not used.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ </sect1>
+
+ <sect1 id="color-which">
+ <title>Configuring the Colors</title>
+
+ <para>
+ The actual colors to be used are configured using the environment variable
+ <envar>PG_COLORS</envar><indexterm><primary>PG_COLORS</primary></indexterm>
+ (note plural). The value is a colon-separated list of
+ <literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal>
+ pairs. The keys specify what the color is to be used for. The values are
+ SGR (Select Graphic Rendition) specifications, which are interpreted by the
+ terminal.
+ </para>
+
+ <para>
+ The default value is <literal>error=01;31:warning=01;35:locus=01</literal>.
+ </para>
+
+ <tip>
+ <para>
+ This color specification format is also used by other software packages
+ such as <productname>GCC</productname>, <productname>GNU
+ coreutils</productname>, and <productname>GNU grep</productname>.
+ </para>
+ </tip>
+ </sect1>
+</appendix>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 3da2365ea9..1043d0f7ab 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -170,6 +170,7 @@
<!ENTITY limits SYSTEM "limits.sgml">
<!ENTITY acronyms SYSTEM "acronyms.sgml">
+<!ENTITY color SYSTEM "color.sgml">
<!ENTITY features-supported SYSTEM "features-supported.sgml">
<!ENTITY features-unsupported SYSTEM "features-unsupported.sgml">
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index e59cba7997..1f7bd32878 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -278,6 +278,7 @@ <title>Appendixes</title>
&docguide;
&limits;
&acronyms;
+ &color;
</part>
--
2.25.0
Attachments:
[text/plain] v2-0001-Document-color-support.patch (3.4K, ../../afc175cd-902b-3ee9-9cee-f709cadb9c23@2ndquadrant.com/2-v2-0001-Document-color-support.patch)
download | inline diff:
From 7164d4196ace14a1acc9077a7a4d32e57131ff6e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Mon, 23 Mar 2020 09:22:50 +0100
Subject: [PATCH v2] Document color support
Add a documentation appendix that explains the PG_COLOR and PG_COLORS
environment variables.
---
doc/src/sgml/color.sgml | 71 ++++++++++++++++++++++++++++++++++++++
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/postgres.sgml | 1 +
3 files changed, 73 insertions(+)
create mode 100644 doc/src/sgml/color.sgml
diff --git a/doc/src/sgml/color.sgml b/doc/src/sgml/color.sgml
new file mode 100644
index 0000000000..c30b1942a5
--- /dev/null
+++ b/doc/src/sgml/color.sgml
@@ -0,0 +1,71 @@
+<!-- doc/src/sgml/color.sgml -->
+
+<appendix id="color">
+ <title>Color Support</title>
+
+ <indexterm zone="color">
+ <primary>color</primary>
+ </indexterm>
+
+ <para>
+ Most programs in the PostgreSQL package can produce colorized console
+ output. This appendix describes how that is configured.
+ </para>
+
+ <sect1 id="color-when">
+ <title>When Color is Used</title>
+
+ <para>
+ To use colorized output, set the environment variable
+ <envar>PG_COLOR</envar><indexterm><primary>PG_COLOR</primary></indexterm>
+ as follows:
+
+ <orderedlist>
+ <listitem>
+ <para>
+ If the value is <literal>always</literal>, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the value is <literal>auto</literal> and the standard error stream
+ is associated with a terminal device, then color is used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Otherwise, color is not used.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ </sect1>
+
+ <sect1 id="color-which">
+ <title>Configuring the Colors</title>
+
+ <para>
+ The actual colors to be used are configured using the environment variable
+ <envar>PG_COLORS</envar><indexterm><primary>PG_COLORS</primary></indexterm>
+ (note plural). The value is a colon-separated list of
+ <literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal>
+ pairs. The keys specify what the color is to be used for. The values are
+ SGR (Select Graphic Rendition) specifications, which are interpreted by the
+ terminal.
+ </para>
+
+ <para>
+ The default value is <literal>error=01;31:warning=01;35:locus=01</literal>.
+ </para>
+
+ <tip>
+ <para>
+ This color specification format is also used by other software packages
+ such as <productname>GCC</productname>, <productname>GNU
+ coreutils</productname>, and <productname>GNU grep</productname>.
+ </para>
+ </tip>
+ </sect1>
+</appendix>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 3da2365ea9..1043d0f7ab 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -170,6 +170,7 @@
<!ENTITY limits SYSTEM "limits.sgml">
<!ENTITY acronyms SYSTEM "acronyms.sgml">
+<!ENTITY color SYSTEM "color.sgml">
<!ENTITY features-supported SYSTEM "features-supported.sgml">
<!ENTITY features-unsupported SYSTEM "features-unsupported.sgml">
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index e59cba7997..1f7bd32878 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -278,6 +278,7 @@ <title>Appendixes</title>
&docguide;
&limits;
&acronyms;
+ &color;
</part>
--
2.25.0
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-24 14:34 Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 1 reply; 34+ messages in thread
From: Juan José Santamaría Flecha @ 2020-03-24 14:34 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Mon, Mar 23, 2020 at 9:32 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:
>
> I'm giving up on making color the default, since there is clearly no
> consensus.
>
> Attached is the documentation patch reworked.
>
I think there is also some value in adding the functionality proposed in
terminal_supports_color().
Regards,
Juan José Santamaría Flecha
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-26 06:36 Michael Paquier <michael@paquier.xyz>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 1 reply; 34+ messages in thread
From: Michael Paquier @ 2020-03-26 06:36 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Mon, Mar 23, 2020 at 09:32:08AM +0100, Peter Eisentraut wrote:
> Attached is the documentation patch reworked.
Thanks!
> Should we delete all the repetitive mentions on the man pages?
I am not sure that deleting all the mentions would be a good idea, as
we'd lose track of which tool supports coloring or not, and that could
confuse users. What about switching the existing paragraph to a
simple sentence with a link to the new appendix you are adding? Say:
"pg_foo supports <place_your_link_here>colorized output</>".
> + <para>
> + The actual colors to be used are configured using the environment variable
> + <envar>PG_COLORS</envar><indexterm><primary>PG_COLORS</primary></indexterm>
> + (note plural). The value is a colon-separated list of
> + <literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal>
> + pairs. The keys specify what the color is to be used for. The values are
> + SGR (Select Graphic Rendition) specifications, which are interpreted by the
> + terminal.
> + </para>
A reference to SGR to understand better what's the list of values
supported would be nice?
> + <para>
> + The default value is <literal>error=01;31:warning=01;35:locus=01</literal>.
> + </para>
Could it be possible to have more details about what those three
fields map to?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20200326063625.GG1471@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-29 09:56 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 34+ messages in thread
From: Peter Eisentraut @ 2020-03-29 09:56 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On 2020-03-26 07:36, Michael Paquier wrote:
> I am not sure that deleting all the mentions would be a good idea, as
> we'd lose track of which tool supports coloring or not, and that could
> confuse users. What about switching the existing paragraph to a
> simple sentence with a link to the new appendix you are adding? Say:
> "pg_foo supports <place_your_link_here>colorized output</>".
I didn't do this because it would create additional complications in the
man pages. But there is now an index entry, so it's possible to find
more information.
>> + <para>
>> + The actual colors to be used are configured using the environment variable
>> + <envar>PG_COLORS</envar><indexterm><primary>PG_COLORS</primary></indexterm>
>> + (note plural). The value is a colon-separated list of
>> + <literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal>
>> + pairs. The keys specify what the color is to be used for. The values are
>> + SGR (Select Graphic Rendition) specifications, which are interpreted by the
>> + terminal.
>> + </para>
>
> A reference to SGR to understand better what's the list of values
> supported would be nice?
I'm not sure how to do that. The full list of possible values is huge,
and exactly what is supported depends on the terminal.
>> + <para>
>> + The default value is <literal>error=01;31:warning=01;35:locus=01</literal>.
>> + </para>
>
> Could it be possible to have more details about what those three
> fields map to?
I have added information about that and explained the example values. I
think if you search for "Select Graphic Rendition" and look for the
example values, you can make sense of this.
Committed with those changes. This closes the commit fest item.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-29 09:56 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
0 siblings, 1 reply; 34+ messages in thread
From: Peter Eisentraut @ 2020-03-29 09:56 UTC (permalink / raw)
To: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On 2020-03-24 15:34, Juan José Santamaría Flecha wrote:
> I think there is also some value in adding the functionality proposed in
> terminal_supports_color().
What do you want to do with that functionality?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-29 12:55 Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 34+ messages in thread
From: Juan José Santamaría Flecha @ 2020-03-29 12:55 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Sun, Mar 29, 2020 at 11:56 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:
> On 2020-03-24 15:34, Juan José Santamaría Flecha wrote:
> > I think there is also some value in adding the functionality proposed in
> > terminal_supports_color().
>
> What do you want to do with that functionality?
Add it to the tests done when PG_COLOR is "auto".
Regards
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-30 08:03 Michael Paquier <michael@paquier.xyz>
parent: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
0 siblings, 1 reply; 34+ messages in thread
From: Michael Paquier @ 2020-03-30 08:03 UTC (permalink / raw)
To: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Sun, Mar 29, 2020 at 02:55:37PM +0200, Juan José Santamaría Flecha wrote:
> Add it to the tests done when PG_COLOR is "auto".
FWIW, I am not sure that it is a good idea to stick into the code
knowledge inherent to TERM. That would likely rot depending on how
terminals evolve in the future, and it is easy to test if a terminal
supports color or not but just switching PG_COLOR in a given
environment and look at the error message produced by anything
able to support coloring.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20200330080346.GF43995@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-03-30 08:08 Michael Paquier <michael@paquier.xyz>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 34+ messages in thread
From: Michael Paquier @ 2020-03-30 08:08 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Sun, Mar 29, 2020 at 11:56:15AM +0200, Peter Eisentraut wrote:
> I didn't do this because it would create additional complications in the man
> pages. But there is now an index entry, so it's possible to find more
> information.
Cannot you add a link to the page for color support in each one of
them? That seems more user-friendly to me.
> I'm not sure how to do that. The full list of possible values is huge, and
> exactly what is supported depends on the terminal.
An idea is to add a reference to SGR parameters directly from
wikipedia:
https://en.wikipedia.org/wiki/ANSI_escape_code
However I recall that you don't like adding references to
Wiki-sensei. Please feel free to discard this idea if you don't like
it.
> Committed with those changes. This closes the commit fest item.
Thanks for the addition.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20200330080816.GG43995@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-04-01 13:50 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 34+ messages in thread
From: Peter Eisentraut @ 2020-04-01 13:50 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; Gavin Flower <GavinFlower@archidevsys.co.nz>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On 2020-03-30 10:03, Michael Paquier wrote:
> On Sun, Mar 29, 2020 at 02:55:37PM +0200, Juan José Santamaría Flecha wrote:
>> Add it to the tests done when PG_COLOR is "auto".
>
> FWIW, I am not sure that it is a good idea to stick into the code
> knowledge inherent to TERM. That would likely rot depending on how
> terminals evolve in the future, and it is easy to test if a terminal
> supports color or not but just switching PG_COLOR in a given
> environment and look at the error message produced by anything
> able to support coloring.
There could be some value in this, I think. Other systems also do this
in some variant. However, it's unclear to me to what extent this is
legacy behavior or driven by current needs. I'd be willing to refine
this, but it should be based on some actual needs. What terminals (or
terminal-like things) don't support color, and how do we detect them?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-04-01 13:52 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 34+ messages in thread
From: Peter Eisentraut @ 2020-04-01 13:52 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; pgsql-hackers
On 2020-03-30 10:08, Michael Paquier wrote:
> On Sun, Mar 29, 2020 at 11:56:15AM +0200, Peter Eisentraut wrote:
>> I didn't do this because it would create additional complications in the man
>> pages. But there is now an index entry, so it's possible to find more
>> information.
>
> Cannot you add a link to the page for color support in each one of
> them? That seems more user-friendly to me.
Do you have a specific phrasing or look in mind?
>> I'm not sure how to do that. The full list of possible values is huge, and
>> exactly what is supported depends on the terminal.
>
> An idea is to add a reference to SGR parameters directly from
> wikipedia:
> https://en.wikipedia.org/wiki/ANSI_escape_code
> However I recall that you don't like adding references to
> Wiki-sensei. Please feel free to discard this idea if you don't like
> it.
Yeah, we could perhaps do this.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 34+ messages in thread
* Re: color by default
@ 2020-04-02 07:22 Michael Paquier <michael@paquier.xyz>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 0 replies; 34+ messages in thread
From: Michael Paquier @ 2020-04-02 07:22 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; pgsql-hackers
On Wed, Apr 01, 2020 at 03:52:17PM +0200, Peter Eisentraut wrote:
> On 2020-03-30 10:08, Michael Paquier wrote:
>> Cannot you add a link to the page for color support in each one of
>> them? That seems more user-friendly to me.
>
> Do you have a specific phrasing or look in mind?
I actually do. Please see the attached, which seems to bring more
consistency across all the docs for all the tools.
>> An idea is to add a reference to SGR parameters directly from
>> wikipedia:
>> https://en.wikipedia.org/wiki/ANSI_escape_code
>> However I recall that you don't like adding references to
>> Wiki-sensei. Please feel free to discard this idea if you don't like
>> it.
>
> Yeah, we could perhaps do this.
Actually, the standard ECMA-48 could just be directly used for that:
https://www.ecma-international.org/publications/standards/Ecma-048.htm
So, what do you think?
--
Michael
Attachments:
[text/x-diff] docs-color.patch (22.5K, ../../20200402072255.GC112468@paquier.xyz/2-docs-color.patch)
download | inline diff:
diff --git a/doc/src/sgml/color.sgml b/doc/src/sgml/color.sgml
index a01a0c778f..2d5ca23dde 100644
--- a/doc/src/sgml/color.sgml
+++ b/doc/src/sgml/color.sgml
@@ -52,8 +52,8 @@
(note plural). The value is a colon-separated list of
<literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal>
pairs. The keys specify what the color is to be used for. The values are
- SGR (Select Graphic Rendition) specifications, which are interpreted by the
- terminal.
+ <ulink url="https://www.ecma-international.org/publications/standards/Ecma-048.htm">SGR (Select Graphic Rendition) specifications</ulink>,
+ which are interpreted by the terminal.
</para>
<para>
diff --git a/doc/src/sgml/oid2name.sgml b/doc/src/sgml/oid2name.sgml
index dfe3682739..9cc33a1678 100644
--- a/doc/src/sgml/oid2name.sgml
+++ b/doc/src/sgml/oid2name.sgml
@@ -216,6 +216,18 @@
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
<para>
@@ -223,13 +235,6 @@
utilities, also uses the environment variables supported by
<application>libpq</application> (see <xref linkend="libpq-envars"/>).
</para>
-
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/clusterdb.sgml b/doc/src/sgml/ref/clusterdb.sgml
index 177856ca74..cf86cfdbd1 100644
--- a/doc/src/sgml/ref/clusterdb.sgml
+++ b/doc/src/sgml/ref/clusterdb.sgml
@@ -277,11 +277,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/createdb.sgml b/doc/src/sgml/ref/createdb.sgml
index 2fca26237e..78b192051b 100644
--- a/doc/src/sgml/ref/createdb.sgml
+++ b/doc/src/sgml/ref/createdb.sgml
@@ -325,11 +325,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/createuser.sgml b/doc/src/sgml/ref/createuser.sgml
index 9d24df8b7a..005a2f0050 100644
--- a/doc/src/sgml/ref/createuser.sgml
+++ b/doc/src/sgml/ref/createuser.sgml
@@ -403,11 +403,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/dropdb.sgml b/doc/src/sgml/ref/dropdb.sgml
index 28b18bfcb0..e24e8d4b3c 100644
--- a/doc/src/sgml/ref/dropdb.sgml
+++ b/doc/src/sgml/ref/dropdb.sgml
@@ -243,11 +243,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/dropuser.sgml b/doc/src/sgml/ref/dropuser.sgml
index f9aab340d3..47c312e6e0 100644
--- a/doc/src/sgml/ref/dropuser.sgml
+++ b/doc/src/sgml/ref/dropuser.sgml
@@ -223,11 +223,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/initdb.sgml b/doc/src/sgml/ref/initdb.sgml
index a04a180165..ad3119786a 100644
--- a/doc/src/sgml/ref/initdb.sgml
+++ b/doc/src/sgml/ref/initdb.sgml
@@ -464,11 +464,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index c8e040bacf..a076df0e91 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -707,18 +707,25 @@ PostgreSQL documentation
<refsect1>
<title>Environment</title>
+ <variablelist>
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
<para>
This utility, like most other <productname>PostgreSQL</productname> utilities,
uses the environment variables supported by <application>libpq</application>
(see <xref linkend="libpq-envars"/>).
</para>
-
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/pg_checksums.sgml b/doc/src/sgml/ref/pg_checksums.sgml
index 6baf9deaae..67fdf1cd90 100644
--- a/doc/src/sgml/ref/pg_checksums.sgml
+++ b/doc/src/sgml/ref/pg_checksums.sgml
@@ -189,11 +189,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pg_controldata.sgml b/doc/src/sgml/ref/pg_controldata.sgml
index 4aae8b193d..017d463ee5 100644
--- a/doc/src/sgml/ref/pg_controldata.sgml
+++ b/doc/src/sgml/ref/pg_controldata.sgml
@@ -71,11 +71,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index a9bc397165..f3c5a1dff8 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -1257,11 +1257,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pg_dumpall.sgml b/doc/src/sgml/ref/pg_dumpall.sgml
index f0859896c5..92362df408 100644
--- a/doc/src/sgml/ref/pg_dumpall.sgml
+++ b/doc/src/sgml/ref/pg_dumpall.sgml
@@ -699,11 +699,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pg_isready.sgml b/doc/src/sgml/ref/pg_isready.sgml
index 3d5b551b87..8742085e5f 100644
--- a/doc/src/sgml/ref/pg_isready.sgml
+++ b/doc/src/sgml/ref/pg_isready.sgml
@@ -158,6 +158,20 @@ PostgreSQL documentation
<refsect1>
<title>Environment</title>
+ <variablelist>
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
<para>
<command>pg_isready</command>, like most other <productname>PostgreSQL</productname>
utilities,
@@ -165,12 +179,6 @@ PostgreSQL documentation
(see <xref linkend="libpq-envars"/>).
</para>
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
</refsect1>
<refsect1 id="app-pg-isready-notes">
diff --git a/doc/src/sgml/ref/pg_receivewal.sgml b/doc/src/sgml/ref/pg_receivewal.sgml
index febfc0ba13..34ce8887a7 100644
--- a/doc/src/sgml/ref/pg_receivewal.sgml
+++ b/doc/src/sgml/ref/pg_receivewal.sgml
@@ -412,18 +412,25 @@ PostgreSQL documentation
<refsect1>
<title>Environment</title>
+ <variablelist>
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
<para>
This utility, like most other <productname>PostgreSQL</productname> utilities,
uses the environment variables supported by <application>libpq</application>
(see <xref linkend="libpq-envars"/>).
</para>
-
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/pg_recvlogical.sgml b/doc/src/sgml/ref/pg_recvlogical.sgml
index 41508fdc1e..92d9cfe0b3 100644
--- a/doc/src/sgml/ref/pg_recvlogical.sgml
+++ b/doc/src/sgml/ref/pg_recvlogical.sgml
@@ -392,18 +392,25 @@ PostgreSQL documentation
<refsect1>
<title>Environment</title>
+ <variablelist>
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
<para>
This utility, like most other <productname>PostgreSQL</productname> utilities,
uses the environment variables supported by <application>libpq</application>
(see <xref linkend="libpq-envars"/>).
</para>
-
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/pg_resetwal.sgml b/doc/src/sgml/ref/pg_resetwal.sgml
index 3b6c32c8d3..5cb067ba38 100644
--- a/doc/src/sgml/ref/pg_resetwal.sgml
+++ b/doc/src/sgml/ref/pg_resetwal.sgml
@@ -326,11 +326,12 @@ PostgreSQL documentation
<variablelist>
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pg_restore.sgml b/doc/src/sgml/ref/pg_restore.sgml
index e9a145ad6e..25ff8d9795 100644
--- a/doc/src/sgml/ref/pg_restore.sgml
+++ b/doc/src/sgml/ref/pg_restore.sgml
@@ -825,11 +825,12 @@
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index 07c49e4719..feef5bef82 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -274,18 +274,25 @@ PostgreSQL documentation
<refsect1>
<title>Environment</title>
+ <variablelist>
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
<para>
When <option>--source-server</option> option is used,
<application>pg_rewind</application> also uses the environment variables
supported by <application>libpq</application> (see <xref linkend="libpq-envars"/>).
</para>
-
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/pg_waldump.sgml b/doc/src/sgml/ref/pg_waldump.sgml
index 667093f060..00f7db9f8a 100644
--- a/doc/src/sgml/ref/pg_waldump.sgml
+++ b/doc/src/sgml/ref/pg_waldump.sgml
@@ -221,11 +221,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pgarchivecleanup.sgml b/doc/src/sgml/ref/pgarchivecleanup.sgml
index 84c2df572a..5c7968b86a 100644
--- a/doc/src/sgml/ref/pgarchivecleanup.sgml
+++ b/doc/src/sgml/ref/pgarchivecleanup.sgml
@@ -150,12 +150,19 @@ pg_archivecleanup: removing file "archive/00000001000000370000000E"
<refsect1>
<title>Environment</title>
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
+ <variablelist>
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</refsect1>
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 41b3880c91..5207aa1518 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -898,6 +898,18 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
<para>
@@ -905,13 +917,6 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
uses the environment variables supported by <application>libpq</application>
(see <xref linkend="libpq-envars"/>).
</para>
-
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/pgtestfsync.sgml b/doc/src/sgml/ref/pgtestfsync.sgml
index c6aa5673f1..a027f1de8f 100644
--- a/doc/src/sgml/ref/pgtestfsync.sgml
+++ b/doc/src/sgml/ref/pgtestfsync.sgml
@@ -106,12 +106,19 @@
<refsect1>
<title>Environment</title>
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
+ <variablelist>
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 39f58c4ea2..58cdaaabfc 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -4499,11 +4499,12 @@ $endif
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/reindexdb.sgml b/doc/src/sgml/ref/reindexdb.sgml
index f6c3d9538b..6394f851f7 100644
--- a/doc/src/sgml/ref/reindexdb.sgml
+++ b/doc/src/sgml/ref/reindexdb.sgml
@@ -378,11 +378,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/vacuumdb.sgml b/doc/src/sgml/ref/vacuumdb.sgml
index fd1dc140ab..b4edccaf79 100644
--- a/doc/src/sgml/ref/vacuumdb.sgml
+++ b/doc/src/sgml/ref/vacuumdb.sgml
@@ -472,11 +472,12 @@ PostgreSQL documentation
<varlistentry>
<term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
<listitem>
<para>
- Specifies whether to use color in diagnostic messages. Possible values
- are <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/vacuumlo.sgml b/doc/src/sgml/vacuumlo.sgml
index 26b764d54b..ae3f700d3f 100644
--- a/doc/src/sgml/vacuumlo.sgml
+++ b/doc/src/sgml/vacuumlo.sgml
@@ -189,6 +189,18 @@
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><envar>PG_COLOR</envar></term>
+ <term><envar>PG_COLORS</envar></term>
+
+ <listitem>
+ <para>
+ Specifies whether and how to use color in diagnostic messages (see
+ <xref linkend="color"/> for details).
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
<para>
@@ -196,13 +208,6 @@
also uses the environment variables supported by <application>libpq</application>
(see <xref linkend="libpq-envars"/>).
</para>
-
- <para>
- The environment variable <envar>PG_COLOR</envar> specifies whether to use
- color in diagnostic messages. Possible values are
- <literal>always</literal>, <literal>auto</literal> and
- <literal>never</literal>.
- </para>
</refsect1>
<refsect1>
[application/pgp-signature] signature.asc (832B, ../../20200402072255.GC112468@paquier.xyz/3-signature.asc)
download
^ permalink raw reply [nested|flat] 34+ messages in thread
end of thread, other threads:[~2020-04-02 07:22 UTC | newest]
Thread overview: 34+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-12-31 10:40 color by default Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-12-31 12:13 ` Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
2019-12-31 13:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-12-31 13:52 ` Abel Abraham Camarillo Ojeda <acamari@verlet.org>
2019-12-31 13:59 ` Daniel Gustafsson <daniel@yesql.se>
2019-12-31 14:12 ` Andreas Joseph Krogh <andreas@visena.com>
2019-12-31 15:18 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2019-12-31 15:46 ` Isaac Morland <isaac.morland@gmail.com>
2019-12-31 17:32 ` Jose Luis Tallon <jltallon@adv-solutions.net>
2020-01-02 23:38 ` Gavin Flower <GavinFlower@archidevsys.co.nz>
2020-01-03 18:10 ` Robert Haas <robertmhaas@gmail.com>
2020-01-06 05:38 ` Michael Paquier <michael@paquier.xyz>
2020-01-06 07:26 ` Gavin Flower <GavinFlower@archidevsys.co.nz>
2020-03-02 12:00 ` Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
2020-03-03 05:31 ` Michael Paquier <michael@paquier.xyz>
2020-03-20 02:15 ` Bruce Momjian <bruce@momjian.us>
2020-03-21 02:55 ` Bruce Momjian <bruce@momjian.us>
2020-03-21 03:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-03-21 03:22 ` Bruce Momjian <bruce@momjian.us>
2020-03-23 05:04 ` Michael Paquier <michael@paquier.xyz>
2020-03-23 08:32 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-03-24 14:34 ` Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
2020-03-29 09:56 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-03-29 12:55 ` Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
2020-03-30 08:03 ` Michael Paquier <michael@paquier.xyz>
2020-04-01 13:50 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-03-26 06:36 ` Michael Paquier <michael@paquier.xyz>
2020-03-29 09:56 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-03-30 08:08 ` Michael Paquier <michael@paquier.xyz>
2020-04-01 13:52 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-04-02 07:22 ` Michael Paquier <michael@paquier.xyz>
2020-01-03 20:25 ` Jeff Janes <jeff.janes@gmail.com>
2020-03-21 04:25 ` Jonah H. Harris <jonah.harris@gmail.com>
2020-03-21 13:30 ` Isaac Morland <isaac.morland@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox