Petr Jelinek <petr@2ndquadrant.com> writes:
> On 12/03/16 04:30, Tom Lane wrote:
>> 1. I found two places (marked XXX in this patch) that are using strtoul()
>> to parse a tuple count back out of a command tag. That won't do anymore.
>> pg_stat_statements has a messy hack for the same problem (look for
>> HAVE_STRTOULL), which is probably what we want to do, but not by
>> copy-and-pasting #ifdef HAVE_STRTOULL into multiple places. I'd be
>> inclined to provide a utility function "pg_strtouint64" or some such
>> to encapsulate that. (numutils.c might be a good place for it.)
> Hmm, I thought that solution is not really portable for 64bit numbers
> and only is allowed in pg_stat_statements because worst case it will cut
> the number to 32bit int and misreport but won't break anything there.
> For example windows IIRC need _strtoui64 for this.
OK, we can use _strtoui64() on Windows.
> I once wrote (well copy-pasted from BDS + some #define wrappers)
> portable version of that, see the 0004 and bottom of 0003 in
> http://www.postgresql.org/message-id/557D9DED.2080204@2ndquadrant.com (I
> think at minimum what the 0003 does in c.h is needed).
Meh. That seems like pretty substantial overkill. Given that we assume
platforms have working 64-bit support these days, what's the probability
that they don't have an appropriate strtoXXX function? Or on one that
doesn't, that anyone will ever try to run >4G-tuple results through the
relevant code paths?
For the moment I'm just going to do this:
uint64
pg_strtouint64(const char *str, char **endptr, int base)
{
#ifdef WIN32return _strtoui64(str, endptr, base);
#elif defined(HAVE_STRTOULL) && SIZEOF_LONG < 8return strtoull(str, endptr, base);
#elsereturn strtoul(str, endptr, base);
#endif
}
If there ever seems to be any practical value in improving it, we
can do that later.
regards, tom lane