Re: "long" type is not appropriate for counting tuples - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: "long" type is not appropriate for counting tuples
Date
Msg-id CAH2-WznpOKSFjhCefENaGQPLd0T+swCmVfQ4tSqnmQ-Z6ZVX+A@mail.gmail.com
Whole thread Raw
In response to Re: "long" type is not appropriate for counting tuples  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Apr 28, 2019 at 4:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > ISTM that we should try to come up with a way of making code like this
> > work, rather than placing the burden on new code to get it right.
>
> Other than "use the right datatype", I'm not sure what we can do?

Ambiguity seems like the real problem here. If we could impose a
general rule that you cannot use "long" (perhaps with some limited
wiggle-room), then a lint-like tool could catch bugs like this. This
may not be that difficult. Nobody is particularly concerned about
performance on 32-bit platforms these days.

> In the meantime, somebody should fix ab0dfc961b6 ...

I'll leave this to Alvaro.

> Hmm, why is this a problem?  We should only use off_t for actual file
> access operations, and we don't use files greater than 1GB.  (There's a
> reason for that.)

The issue that was fixed by commit aa551830 showed this assumption to
be kind of brittle. Admittedly this is not as clear-cut as the "long"
issue, and might not be worth worrying about. I don't want to go as
far as requiring explicit width integer types in all situations, since
that seems totally impractical, and without any real upside. But it
would be nice to identify integer types where there is a real risk of
making an incorrect assumption, and then eliminate that risk once and
for all.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "long" type is not appropriate for counting tuples
Next
From: Noah Misch
Date:
Subject: Re: Speed up build on Windows by generating symbol definition inbatch