Re: Use of "long" in incremental sort code

On 11/4/20 10:58 PM, David Rowley wrote:
> On Wed, 4 Nov 2020 at 10:42, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> IMHO this should simply switch the current int64 variable to long, as it
>> was before. Not sure about about the hashagg uint64 variable.
>
> IMO, we should just get rid of the use of "long" here. As far as I'm
> concerned, using long in the core code at all is just unnecessary and
> just increases the chances of having bugs.
>
> How often do people forget that we support a 64-bit platform that has
> sizeof(long) == 4?
>
> Can't we use size_t and ssize_t if we really need a processor
> word-sized type? And use int64/uint64 when we really want a 64-bit
> type.
>

Perhaps. But I guess it's a bit strange to have function declared as
returning long, but store the result in int64 everywhere. That was the
point I was trying to make - it's not just a matter of changing all the
variables to int64, IMHO.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company