From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove pg_strtouint64(), use strtoull() directly |
Date: | 2021-12-13 14:44:32 |
Message-ID: | 822554.1639406672@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-12-13 14:52:15 | Re: should we enable log_checkpoints out of the box? |
Previous Message | Shruthi Gowda | 2021-12-13 14:40:45 | Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce) |