From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: David Fetter <david@fetter.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Finer grain log timestamps
Date: Mon, 20 Jun 2022 13:05:14 +0200
Message-ID: <20220620110514.athzygshxtln3yt6@alvherre.pgsql> (raw)
In-Reply-To: <20220614000545.GE12494@fetter.org>
On 2022-Jun-14, David Fetter wrote:
> On Mon, Jun 13, 2022 at 04:22:42PM -0400, Tom Lane wrote:
> > A different line of thought is to extend %t to provide a precision
> > field a la sprintf, so that for example "%.3t" is equivalent to
> > "%m" and "%.6t" does what David wants, and we won't have to
> > search for a new escape letter when the day arrives that
> > somebody wants nanosecond resolution. The same could be done
> > with %n, avoiding the need to find a different escape letter
> > for that.
>
> I'll build this more sprintf-like thing if not doing so prevents the
> change from happening, but frankly, I don't really see a point in it
> because the next "log timestamps at some random negative power of 10
> second granularity" requirement I see will be the first.
Do we *have* to provide support for arbitrary numbers of digits, though?
We could provide support for only %.3t and %.6t specifically, and not
worry about other cases (error: width not supported). When somebody
wants %.9t in ten years, we won't have to fight for which letter to
pick. And I agree that widening %m for everybody without recourse is
not great.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@alvh.no-ip.org, david@fetter.org, tgl@sss.pgh.pa.us, robertmhaas@gmail.com
Subject: Re: Finer grain log timestamps
In-Reply-To: <20220620110514.athzygshxtln3yt6@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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