Re: Printing LSN made easy - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Printing LSN made easy
Date
Msg-id 20201130143738.GA15557@alvherre.pgsql
Whole thread Raw
In response to Re: Printing LSN made easy  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Printing LSN made easy  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
On 2020-Nov-30, Ashutosh Bapat wrote:

> Peter Eisentraut explained that the translation system can not handle
> strings broken by macros, e.g. errmsg("foo" MACRO "bar"), since it doesn't
> know statically what the macro resolves to. But I am not familiar with our
> translation system myself. But if we allow INT64_FORMAT, LSN_FORMAT should
> be allowed. That makes life much easier. We do not need other functions at
> all.
> 
> Peter E or somebody familiar with translations can provide more
> information.

We don't allow INT64_FORMAT in translatable strings, period.  (See
commit 6a1cd8b9236d which undid some hacks we had to use to work around
the lack of it, by allowing %llu to take its place.)  For the same
reason, we cannot allow LSN_FORMAT or similar constructions in
translatable strings either.

If the solution to ugliness of LSN printing is going to require that we
add a "%s" which prints a previously formatted string with LSN_FORMAT,
it won't win us anything.

As annoyed as I am about our LSN printing, I don't think this patch
has the solutions we need.



pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Re: [PATCH] Keeps tracking the uniqueness with UniqueKey
Next
From: Muhammad Usama
Date:
Subject: Re: A new function to wait for the backend exit after termination