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

Поиск
Список
Период
Сортировка
От Pavel Borisov
Тема Re: [PATCH] Remove workarounds to format [u]int64's
Дата
Msg-id CALT9ZEH+00ocApVC42ttwJYJ-4FyP5-FsQ0-0UyZ5bhxD+LjOQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Remove workarounds to format [u]int64's  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
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.


--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
Следующее
От: Andres Freund
Дата:
Сообщение: Re: multithreaded zstd backup compression for client and server