Re: Printing LSN made easy

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
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-12-03 06:38:39
Message-ID: CAGEoWWR8WeC8waYX1ucwmGa0Xs5ZnORLoPFW-GO_-cAQGVRTww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 30, 2020 at 8:07 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> 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.
>

Thanks for the commit. The commit reverted code which uses a char array to
print int64. On the same lines, using a character array to print an LSN
won't be acceptable. I agree.

Maybe we should update the section "Message-Writing Guidelines" in
doc/src/sgml/nls.sgml. I think it's implied by "Do not construct sentences
at run-time, like ... " but using a macro is not really constructing
sentences run time. Hopefully, some day, we will fix the translation system
to handle strings with macros and make it easier to print PG specific
objects in strings easily.

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

I think we could at least accept the macros so that they can be used in
non-translatable strings i.e. use it with sprints, appendStringInfo
variants etc. The macros will also serve to document the string format of
LSN. Developers can then copy from the macros rather than copying from
"some other" (erroneous) usage in the code.

--
Best Wishes,
Ashutosh

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-12-03 06:45:07 Re: Commitfest 2020-11 is closed
Previous Message Masahiko Sawada 2020-12-03 06:33:40 Re: [HACKERS] logical decoding of two-phase transactions