From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, rjuju123(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: INT64_FORMAT in translatable strings |
Date: | 2021-04-23 04:26:09 |
Message-ID: | YIJMYVoupaia9uUg@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)sss(dot)pgh(dot)pa(dot)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.
> - (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!
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-04-23 04:36:56 | Re: Fix redundant comments in fmgr.c |
Previous Message | Tom Lane | 2021-04-23 04:17:35 | Re: Support tab completion for upper character inputs in psql |