Andres Freund <andres@anarazel.de> writes:
> On 2019-04-29 13:32:13 -0400, Tom Lane wrote:
>> There's more to that than you might realize. For example, guc.c
>> enforces a limit on work_mem that's designed to ensure that
>> expressions like "work_mem * 1024L" won't overflow, and there are
>> similar choices elsewhere. I'm not sure if we want to go to the
>> effort of rethinking that; it's not really a bug, though it does
>> result in 64-bit Windows being more restricted than it has to be.
> Hm, but why does that require the use of long? We could fairly trivially
> define a type that's guaranteed to be 32 bit on 32 bit platforms, and 64
> bit on 64 bit platforms. Even a dirty hack like using intptr_t instead
> of long would be better than using long.
The point is that
(a) work_mem is an int; adding support to GUC for some other integer
width would be an unreasonable amount of overhead.
(b) "1024L" is a nice simple non-carpal-tunnel-inducing way to get
the right width of the product, for some value of "right".
If we don't want to rely on "L" constants then we'll have to write these
cases like "work_mem * (size_t) 1024" which is ugly, lots more keystrokes,
and prone to weird precedence problems unless you throw even more
keystrokes (parentheses) at it. I'm not excited about doing that just
to allow larger work_mem settings on Win64.
(But if we do go in this direction, maybe some notation like
#define KILOBYTE ((size_t) 1024)
would help.)
I'm not suggesting that we don't need to fix uses of "long" for tuple
counts, and perhaps other things. But I think getting rid of it in memory
size calculations might be a lot of work for not a lot of reward.
regards, tom lane
