From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: David Fetter <david@fetter.org>, Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Finer grain log timestamps
In-reply-to: <20220620110514.athzygshxtln3yt6@alvherre.pgsql>
References: <20220620110514.athzygshxtln3yt6@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Mon, 20 Jun 2022 13:05:14 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2525298.1655737285.1@sss.pgh.pa.us>
Date: Mon, 20 Jun 2022 11:01:25 -0400
Message-ID: <2525299.1655737285@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2525299.1655737285%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 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).

If I were coding it, I would allow only exactly 1 digit (%.Nt) to simplify
the parsing side of things and bound the required buffer size.  Without
having written it, it's not clear to me whether further restricting the
set of supported values would save much code.  I will point out, though,
that throwing an error during log_line_prefix processing will lead
straight to infinite recursion.

			regards, tom lane