Thread

Re: Some efforts to get rid of "long" in our codebase

David Rowley <dgrowleyml@gmail.com> — 2025-11-10T00:53:36Z

On Fri, 7 Nov 2025 at 07:26, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 06.11.25 13:17, Heikki Linnakangas wrote:
> >> @@ -476,7 +476,7 @@ CatCachePrintStats(int code, Datum arg)
> >>
> >>          if (cache->cc_ntup == 0 && cache->cc_searches == 0)
> >>              continue;            /* don't print unused caches */
> >> -        elog(DEBUG2, "catcache %s/%u: %d tup, %ld srch, %ld+%ld=%ld
> >> hits, %ld+%ld=%ld loads, %ld invals, %d lists, %ld lsrch, %ld lhits",
> >> +        elog(DEBUG2, "catcache %s/%u: %d tup, %" PRIu64 " srch, %"
> >> PRIu64 "+%" PRIu64 "=%" PRIu64 " hits, %" PRIu64 "+%" PRIu64 "=%"
> >> PRIu64 " loads, %" PRIu64 " invals, %d lists, %" PRIu64 " lsrch, %"
> >> PRIu64 " lhits",
> >>               cache->cc_relname,
> >>               cache->cc_indexoid,
> >>               cache->cc_ntup,
> >
> > Unfortunately PRIu64 makes these much longer and less readable. I don't
> > think there's much we can do about that though. Perhaps split the format
> > string to multiple lines?
>
> You could also use unsigned long long int for these, to make the format
> strings more readable.

I couldn't really decide on what's best here. I'd personally rather be
more explicit about the width of the type by using uint64, but on the
other hand, I don't know of any realistic modern hardware/compiler
combination where unsigned long long isn't 64-bit. Certainly, the
format string is easier to read with %llu.

v2-0001 wraps the format string as suggested by Heikki, v3-0001 uses
unsigned long long as suggested by Peter.

v2-0002 is updated to use size_t instead of Size, per Heikki

Any further opinions or votes on v2-0001 vs v3-0001?

David