| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | "Tang, Haiying" <tanghy(dot)fnst(at)cn(dot)fujitsu(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Use of "long" in incremental sort code |
| Date: | 2020-11-04 21:58:44 |
| Message-ID: | CAApHDvqT0u8hLDXoa7VRDYvNmS0_LBbzjQ4mgrFLo8iSSEyb8g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2020-11-04 22:00:17 | Re: Compatible defaults for LEAD/LAG |
| Previous Message | Ranier Vilela | 2020-11-04 21:47:23 | Re: Dereference before NULL check (src/backend/storage/ipc/latch.c) |