Re: Finer grain log timestamps

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Finer grain log timestamps
Дата
Msg-id 20220620110514.athzygshxtln3yt6@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Finer grain log timestamps  (David Fetter <david@fetter.org>)
Ответы Re: Finer grain log timestamps  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pltcl crash on recent macOS
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [BUG] Panic due to incorrect missingContrecPtr after promotion