Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2019-05-23 15:52, Robert Haas wrote:
>> On Thu, May 23, 2019 at 5:31 AM Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.com> wrote:
>>> Another option is that in cases where it doesn't affect storage layouts,
>>> like the counting tuples case that started this thread, code could just
>>> use long long int directly instead of int64. Then if someone wants to
>>> make it 128 bits or 96 bits or whatever it would not be a problem.
>> I think that sort of thing tends not to work out well, because at some
>> point it's likely to be sent out via the wire protocol; at that point
>> we'll need a value of a certain width. Better to use that width right
>> from the beginning.
> Hmm, by that argument, we shouldn't ever use any integer type other than
> int16, int32, and int64.
> I'm thinking for example that pgbench makes a lot of use of int64 and
> printing that out makes quite messy code. Replacing that by long long
> int would make this much nicer and should be pretty harmless relative to
> your concern.
It does seem attractive to use long long in cases where we're not too
fussed about the exact width. OTOH, that reasoning was exactly why we
used "long" in a lot of places back in the day, and sure enough it came
back to bite us.
On the whole I think I could live with a policy that says "tuple counts
shall be 'long long' when being passed around in code, but for persistent
storage or wire-protocol transmission, use 'int64'".
An alternative and much narrower policy is to say it's okay to do this
with an int64 value:
printf("processed %lld tuples", (long long) count);
In such code, all we're assuming is long long >= 64 bits, which
is completely safe per C99, and we dodge the need for a
platform-varying format string.
regards, tom lane