From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "long" type is not appropriate for counting tuples |
Date: | 2019-05-22 15:52:46 |
Message-ID: | 2089.1558540366@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On May 22, 2019 7:39:41 AM PDT, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> On 2019-04-29 19:32, Tom Lane wrote:
>>> 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.
>> Since we control our own snprintf now, this could probably be addressed
>> somehow, right?
> z is for size_t though? Not immediately first how It'd help us?
Yeah, z doesn't reliably translate to int64 either, so it's only useful
when the number you're trying to print is a memory object size.
I don't really see how controlling snprintf is enough to get somewhere
on this. Sure we could invent some new always-64-bit length modifier
and teach snprintf.c about it, but none of the other tools we use
would know about it. I don't want to give up compiler cross-checking
of printf formats, do you?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2019-05-22 16:20:53 | Re: VACUUM fails to parse 0 and 1 as boolean value |
Previous Message | Stas Kelvich | 2019-05-22 15:41:39 | Re: Read-only access to temp tables for 2PC transactions |