> > 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>
