Re: Removing "long int"-related limit on hash table sizes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing "long int"-related limit on hash table sizes
Date
Msg-id 173245.1627239196@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing "long int"-related limit on hash table sizes  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Removing "long int"-related limit on hash table sizes  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
Ranier Vilela <ranier.vf@gmail.com> writes:
> I think int64 is in most cases the counterpart of *long* on Windows.

I'm not particularly on board with s/long/int64/g as a universal
solution.  I think that most of these usages are concerned with
memory sizes and would be better off as "size_t".  We might need
int64 in places where we're concerned with sums of memory usage
across processes, or where the value needs to be allowed to be
negative.  So it'll take case-by-case analysis to do it right.

BTW, one aspect of this that I'm unsure how to tackle is the
common usage of "L" constants; in particular, "work_mem * 1024L"
is a really common idiom that we'll need to get rid of.  Not sure
that grep will be a useful aid for finding those.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: when the startup process doesn't (logging startup delays)
Next
From: Bryn Llewellyn
Date:
Subject: Re: Have I found an interval arithmetic bug?