Re: INT64_FORMAT in translatable strings

At Fri, 23 Apr 2021 13:26:09 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Fri, Apr 23, 2021 at 09:43:09AM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> >> But what I thought Michael was griping about is the use of "int",
> >> which is a noise word here.  Either "long long int" or "long long"
> >> will work, but I think we've preferred the latter because shorter.
> 
> Yep, that's what I meant.  Sorry for the confusion.
> 
> > Yeah, there's no reason for the "int" other than just following the
> > immediate preceding commit 3286065651. I also prefer the shorter
> > notations. Attached.
> 
> Note that 3286065 only worked on signed integers.

Yes. it uses redundant "int" for "long".

> > -                    (uint32) (prefetcher->reader->EndRecPtr << 32),
> > -                    (uint32) (prefetcher->reader->EndRecPtr),
> > [..]
> > +                    LSN_FORMAT_ARGS(prefetcher->reader->EndRecPtr),
> 
> Good catch here.  LSN_FORMAT_ARGS() exists to prevent such errors.
> 
> And applied.  Thanks!

Thanks!

-- 
Kyotaro Horiguchi
NTT Open Source Software Center