Date: Wed, 3 Feb 2021 10:58:59 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: tsunakawa.takay@fujitsu.com, iwata.aya@fujitsu.com,
	k.jamison@fujitsu.com, pgsql-hackers@lists.postgresql.org
Subject: Re: libpq debug log
Message-ID: <20210203135859.GA25472@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210203.111805.1546677784618977625.horikyota.ntt@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2021-Feb-03, Kyotaro Horiguchi wrote:

> Looking the doc mentioned in the comment #39:
> 
> +      <literal>flags</literal> contains flag bits describing the operating mode
> +      of tracing.  If (<literal>flags</literal> &amp; <literal>PQTRACE_OUTPUT_TIMESTAMPS</literal>) is
> +      true, then timestamp is not printed with each message.
> 
> PQTRACE_OUTPUT_TIMESTAMPS is designed to *inhibit* timestamps from
> being prepended. If that is actually intended, the symbol name should
> be PQTRACE_NOOUTPUT_TIMESTAMP. Otherwise, the doc need to be fixed.

I'm pretty sure I named the flag PQTRACE_SUPPRESS_TIMESTAMP (and I
prefer SUPPRESS to NOOUTPUT), because the idea is that the timestamp is
printed by default.  I think that's the sensible decision: applications
prefer to have timestamps, even if there's a tiny bit of overhead.  We
don't want to force them to pass a flag for that.  We only want the
no-timestamp behavior in order to be able to use it for libpq internal
testing.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
"Someone said that it is at least an order of magnitude more work to do
production software than a prototype. I think he is wrong by at least
an order of magnitude."                              (Brian Kernighan)