On Sat, 19 Mar 2022 at 01:12, Tom Lane wrote:
> Japin Li writes:
>> we can rely on %lld/%llu and we decided to use them in translatable strings.
>
> Seems like good cleanup, so pushed. I think though that project style
> is to use "long long" or "unsigned long long", without the unnecessary
>
On Fri, Mar 18, 2022 at 01:12:40PM -0400, Tom Lane wrote:
> Japin Li writes:
> > we can rely on %lld/%llu and we decided to use them in translatable strings.
>
> Seems like good cleanup, so pushed. I think though that project style
> is to use "long long" or "unsigned long long", without the unn
Japin Li writes:
> we can rely on %lld/%llu and we decided to use them in translatable strings.
Seems like good cleanup, so pushed. I think though that project style
is to use "long long" or "unsigned long long", without the unnecessary
"int" --- it certainly makes little sense to do it both way
Hi,
I found the following lines in pg_backup_tar.c.
if (len != th->fileLen)
{
charbuf1[32],
buf2[32];
snprintf(buf1, sizeof(buf1), INT64_FORMAT, (int64) len);
snprintf(buf2, sizeof(buf2), INT64_FORMAT, (int64) th->fileLen);
fat
At Fri, 23 Apr 2021 13:26:09 +0900, Michael Paquier 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 wrote in
> >> But what I thought Michael was griping about is the use of "int",
> >> which is a noise word here. E
On Fri, Apr 23, 2021 at 09:43:09AM +0900, Kyotaro Horiguchi wrote:
> At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane 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 pre
At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane wrote in
> Julien Rouhaud writes:
> > On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
> >> May I ask why you are using "unsigned long long int" rather uint64?
>
> > My understanding is that it's the project standard. See e.g.
> > ht
Julien Rouhaud writes:
> On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
>> May I ask why you are using "unsigned long long int" rather uint64?
> My understanding is that it's the project standard. See e.g.
> https://www.postgresql.org/message-id/1730584.1617836...@sss.pgh.pa.us
On Thu, Apr 22, 2021 at 08:12:25PM +0900, Michael Paquier wrote:
> On Thu, Apr 22, 2021 at 06:56:28PM +0800, Julien Rouhaud wrote:
> > My understanding is that it's the project standard. See e.g.
> > https://www.postgresql.org/message-id/1730584.1617836...@sss.pgh.pa.us
>
> FWIW, I am not questio
On Thu, Apr 22, 2021 at 06:56:28PM +0800, Julien Rouhaud wrote:
> My understanding is that it's the project standard. See e.g.
> https://www.postgresql.org/message-id/1730584.1617836...@sss.pgh.pa.us
FWIW, I am not questioning the format of the specifiers, which is
something I heard about, but th
On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
>
> May I ask why you are using "unsigned long long int" rather uint64?
My understanding is that it's the project standard. See e.g.
https://www.postgresql.org/message-id/1730584.1617836...@sss.pgh.pa.us
On Wed, Apr 21, 2021 at 08:00:00PM +0900, Kyotaro Horiguchi wrote:
> Anyway we can rely on %lld/%llu and we decided to use them in
> translatable strings. So the attached fixes (AFAICS) all instances of
> the macros in translatable strings.
Indeed, good catch. Thanks.
> # I just found 328606565
Hello.
I found the following lines in xlogprefetch.c.
>ereport(LOG,
>(errmsg("recovery finished prefetching at %X/%X; "
>"prefetch = " UINT64_FORMAT ", "
>"skip_hit = " UINT64_FORMAT ", "
...
It is found in ja.po as
"recovery finished pref
13 matches
Mail list logo
