Re: Remove pg_strtouint64(), use strtoull() directly

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Remove pg_strtouint64(), use strtoull() directly
Дата
Msg-id 822554.1639406672@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Remove pg_strtouint64(), use strtoull() directly  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Remove pg_strtouint64(), use strtoull() directly  (Robert Haas <robertmhaas@gmail.com>)
Re: Remove pg_strtouint64(), use strtoull() directly  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 10.12.21 16:25, Tom Lane wrote:
>> Our experience with the variable size of "long" has left a sufficiently
>> bad taste in my mouth that I'm not enthused about adding hard-wired
>> assumptions that "long long" is identical to int64.  So this seems like
>> it's going in the wrong direction, and giving up portability that we
>> might want back someday.

> What kind of scenario do you have in mind?  Someone making their long 
> long int 128 bits?

Yeah, exactly.  That seems like a natural evolution:
    short -> 2 bytes
    int -> 4 bytes
    long -> 8 bytes
    long long -> 16 bytes
so I'm surprised that vendors haven't done that already instead
of inventing hacks like __int128.

Our current hard-coded uses of long long are all written on the
assumption that it's *at least* 64 bits, so we'd survive OK on
such a platform so long as we don't start confusing it with
*exactly* 64 bits.

            regards, tom lane



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

Предыдущее
От: Shruthi Gowda
Дата:
Сообщение: Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: should we enable log_checkpoints out of the box?