From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | rjuju123(at)gmail(dot)com, michael(at)paquier(dot)xyz, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: INT64_FORMAT in translatable strings |
Date: | 2021-04-23 00:43:09 |
Message-ID: | 20210423.094309.606035299195728411.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> Julien Rouhaud <rjuju123(at)gmail(dot)com> 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.1617836485@sss.pgh.pa.us
>
> Indeed, using %lld, %llu, etc with a matching cast to "long long" or
> "unsigned long long" is the approved way. Don't use [u]int64 because
> that does not necessarily match these format specs. It's probably
> physically compatible, but that won't stop pickier compilers from
> nagging about a format mismatch.
>
> 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.
Yeah, there's no reason for the "int" other than just following the
immediate preceding commit 3286065651. I also prefer the shorter
notations. Attached.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Don-t-use-INT64_FORMAT-inside-message-strings-tak.patch | text/x-patch | 4.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-04-23 00:43:10 | Re: multi-install PostgresNode fails with older postgres versions |
Previous Message | Peter Geoghegan | 2021-04-23 00:39:54 | Getting rid of freezing and hint bits by eagerly vacuuming aborted xacts (was: decoupling table and index vacuum) |