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

From David Rowley
Subject Re: Use of "long" in incremental sort code
Date
Msg-id CAApHDvqT0u8hLDXoa7VRDYvNmS0_LBbzjQ4mgrFLo8iSSEyb8g@mail.gmail.com
Whole thread Raw
In response to Re: Use of "long" in incremental sort code  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Use of "long" in incremental sort code  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
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.

David



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)
Next
From: Pavel Stehule
Date:
Subject: Re: Compatible defaults for LEAD/LAG