| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Subject: | Re: "long" type is not appropriate for counting tuples |
| Date: | 2019-06-06 12:50:49 |
| Message-ID: | 320ca812-4f15-bb83-5464-a5d821f19732@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2019-05-23 16:34, Tom Lane wrote:
> On the whole I think I could live with a policy that says "tuple counts
> shall be 'long long' when being passed around in code, but for persistent
> storage or wire-protocol transmission, use 'int64'".
>
> An alternative and much narrower policy is to say it's okay to do this
> with an int64 value:
>
> printf("processed %lld tuples", (long long) count);
>
> In such code, all we're assuming is long long >= 64 bits, which
> is completely safe per C99, and we dodge the need for a
> platform-varying format string.
Some combination of this seems quite reasonable.
Attached is a patch to implement this in a handful of cases that are
particularly verbose right now. I think those are easy wins.
(Also a second patch that makes use of %zu for size_t where this was not
yet done.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Unwind-some-workarounds-for-lack-of-portable-int64-f.patch | text/plain | 8.1 KB |
| 0002-Remove-unnecessary-casts-from-size_t-to-int.patch | text/plain | 3.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2019-06-06 12:58:09 | Re: "long" type is not appropriate for counting tuples |
| Previous Message | Kyotaro Horiguchi | 2019-06-06 11:06:12 | pg_checksums has an untranslatable string. |