"Dave Page" <dpage@vale-housing.co.uk> writes:
> However.... In all but one place in libpq, we don't use errno anyway
> (actually 2, but one is a bug anyway) because we use GetLastError()
> instead (which tested thread safe as well FWIW). The only place it's
> used is PQoidValue():
> result = strtoul(res->cmdStatus + 7, &endptr, 10);
> if (!endptr || (*endptr != ' ' && *endptr != '\0') || errno ==
> ERANGE)
> return InvalidOid;
> else
> return (Oid) result;
> We don't believe strtoul() works with GetLastError() unfortunately. One
> (hackish) solution would be to check that it doesn't return 0 or
> ULONG_MAX.
I'm not sure why we bother with an overflow check there at all. It'd be
worth checking that there is a digit at cmdStatus + 7, but as long as
there is one, it's difficult to see why an overflow check is needed.
The only justification that comes to mind is that if someday there are
versions of Postgres that have 64-bit OIDs, you could get an overflow
here if you had a 32-bit-OID libpq talking to a 64-bit server. However,
I don't see a particularly good reason to return InvalidOid instead of
an overflowed value anyway in that situation. For PQoidValue,
InvalidOid is supposed to mean "there is no OID in this command status"
not "there is an OID but I cannot represent it".
regards, tom lane
