Re: "long" type is not appropriate for counting tuples

Hi,

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.

> Another problem is that while "%lu" format specifiers are portable,
> INT64_FORMAT is a *big* pain, not least because you can't put it into
> translatable strings without causing problems. To the extent that
> we could go over to "%zu" instead, maybe this could be finessed,
> but blind "s/long/int64/g" isn't going to be any fun.

Hm. It appears that gettext supports expanding PRId64 PRIu64 etc in
translated strings. Perhaps we should implement them in our printf, and
then replace all use of INT64_FORMAT with that?

I've not tested the gettext code, but it's there:

/* Expand a system dependent string segment. Return NULL if unsupported. */
static const char *
get_sysdep_segment_value (const char *name)
{
/* Test for an ISO C 99 section 7.8.1 format string directive.
Syntax:
P R I { d | i | o | u | x | X }
{ { | LEAST | FAST } { 8 | 16 | 32 | 64 } | MAX | PTR } */
/* We don't use a table of 14 times 6 'const char *' strings here, because
data relocations cost startup time. */
if (name[0] == 'P' && name[1] == 'R' && name[2] == 'I')
...

Greetings,

Andres Freund