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.vondra@2ndquadrant.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