Re: Finer grain log timestamps

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/