Unified logging system for command-line programs

I have developed a patch that unifies the various ad hoc logging
(message printing, error printing) systems used throughout the
command-line programs.

Examples:

- fprintf(stderr, _("%s: could not open file \"%s\" for writing: %s\n"),
- progname, path, strerror(errno));
+ pg_log_error("could not open file \"%s\" for writing: %m", path);

- if (debug)
- fprintf(stderr,
- _("%s: file \"%s\" would be removed\n"),
- progname, WALFilePath);
+ pg_log_debug("file \"%s\" would be removed", WALFilePath);

Features:

- Program name is automatically prefixed.

- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.

- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.

- I converted error message strings to use %m where possible. (I had
originally intended to implement %m here like elog used to do, but that
was thankfully already done elsewhere.)

- As a result of the above several points, more translatable message
strings can be shared between different components and between frontends
and backend, without gratuitous punctuation or whitespace differences.

- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or verbose
modes, as in the above example.

- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.

- Bonus: Some color in the messages, similar to gcc and clang. Export
PG_COLOR=auto to try it out. The colors are currently hardcoded, so
some configuration there might be added.

- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the context
of the calling program, requiring callbacks, or having to pass
"progname" around everywhere.

Soft goals:

- Reduces vertical space use and visual complexity of error reporting in
the source code.

- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.

- Concepts and terms are vaguely aligned with popular logging frameworks
such as log4j and Python logging.

- Future possibilities. Maybe something like log_line_prefix or
different log formats could be added. Just a theory right now, but this
would make it easier.

Non-goals/out of scope:

- Flow control. This is all just about printing stuff out. Nothing
affects program flow (e.g., fatal exits). The uses are just too varied
to do that. Some existing code had wrappers that do some kind of
print-and-exit, and I adapted those. It didn't seem worth going any
further.

It's not fully complete but most of it works well. I didn't do
pg_upgrade and pg_ctl yet. pg_dump has some remaining special cases to
work through. I tried to keep the output mostly the same, but there is
a lot of historical baggage to unwind and special cases to consider, and
I might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.

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