Feedback-ID: ia2694551:Fastmail
Date: Mon, 20 Jun 2022 13:05:14 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: David Fetter <david@fetter.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Finer grain log timestamps
Message-ID: <20220620110514.athzygshxtln3yt6@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220614000545.GE12494@fetter.org>
Archived-At: 
 <https://www.postgresql.org/message-id/20220620110514.athzygshxtln3yt6%40alvherre.pgsql>
Precedence: bulk

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/