Re: [PATCH] Remove workarounds to format [u]int64's

>
> On 21.03.22 15:37, Aleksander Alekseev wrote:
> >> It would not simplify things for them at all, just mess it up.
> >> The master copies of the .po files are kept in a different repo.
> >> Also, I believe that extraction of new message strings is automated
> >> already.
> >
> > Got it, thanks. Here is the corrected patch. It includes all the
> > changes by me and Japin, and doesn't touch PO files.
>
> I think in some cases we can make this even simpler (and cast-free) by
> changing the underlying variable to be long long instead of int64.
> Especially in cases where the whole point of the variable is to be some
> counter that ends up being printed, there isn't a need to use int64 in
> the first place. See attached patch for examples.

Yes, this will work, when we can define a variable itself as *long long*.
But for some applications: [1], [2], I suppose we'll need exactly uint64 to
represent TransactionId. uint64 is warrantied to fit into *unsigned long
long*, but on most of archs it is just *unsigned long*. Defining what we
need to be uint64 as *unsigned long long* on these archs will mean it
become uint128, which we may not like.

In my opinion, in many places, it's better to have casts when it's for
printing fixed-width int/uint variables than the alternative.

[1]
https://www.postgresql.org/message-id/flat/CACG%3DezYV3FM5i9ws2QLyF%2Brz5WHTqheL59VRsHGsgAwfx8gh4g%40mail.gmail.com#d7068b9d25a2f8a1064d2ea4815df23d
[2]
https://www.postgresql.org/message-id/flat/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>