| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> | 
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> | 
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> | 
| Subject: | Re: Printing LSN made easy | 
| Date: | 2020-11-30 14:37:38 | 
| Message-ID: | 20201130143738.GA15557@alvherre.pgsql | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Muhammad Usama | 2020-11-30 14:39:31 | Re: A new function to wait for the backend exit after termination | 
| Previous Message | Jesper Pedersen | 2020-11-30 14:30:19 | Re: [PATCH] Keeps tracking the uniqueness with UniqueKey |