On 20 February 2016 at 16:32, Tom Lane <t...@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 -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers