Re: pgsql: Fix pg_size_bytes() to be more portable.

On 20 February 2016 at 16:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> After further thought about the portability implications of this ---
>
> 1. We probably gave up support for long-long-less compilers when we agreed
> to start requiring a working int64 type.  On a 32-bit machine that's
> highly likely to be "long long", and 64-bit machines are mostly new enough
> that they'd have C99-compliant compilers.
>
> 2. Nonetheless, LL is not the same as int64; on modern 64-bit machines it
> probably means int128.  So the right thing to do when writing a constant
> you mean to be int64 is to use a cast or [U]INT64CONST().  (You need that
> macro if the constant value might be too wide for plain int, since pickier
> compilers may reject an unsuffixed constant wider than int.)
>

OK, thanks that's all good to know.


> Your updated code looks fine from here.  I looked into changing that code
> in ecpg, but it would be more invasive than I thought because ecpg doesn't
> use c.h.  Some rearrangement of the ecpg headers would be required, and
> in view of point #1, it's unlikely to be worth it; it might buy a bit of
> micro-efficiency but not much.
>

It looks to me as though it doesn't need long long anyway, since the
rotation it's doing can be done just as easily with ints, for example:

    int hashVal = 0;
    for (...)
    {
        hashVal = hashVal + (int) ecpgQuery[stmtIx];
        hashVal = (((unsigned int) hashVal) >> 19) | (hashVal << 13);
    }

but it's probably not worth changing, for risk of breaking it.

Regards,
Dean