Re: Use of "long" in incremental sort code - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Use of "long" in incremental sort code
Date
Msg-id 868a2efa-8e93-2abc-4862-f2964ad8bcb7@enterprisedb.com
Whole thread Raw
In response to Re: Use of "long" in incremental sort code  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Compatible defaults for LEAD/LAG
Next
From: Tomas Vondra
Date:
Subject: Re: Fix brin_form_tuple to properly detoast data