On Wed, Jul 17, 2019 at 07:55:39AM +0000, Fabien COELHO wrote:
>> numutils.c also has pg_strtoint16 and pg_strtoint32, so the locations
>> become rather inconsistent with inconsistent APIs for the manipulation
>> of int2 and int4 fields, and scanint8 is just a derivative of the same
>> logic. We have two categories of routines here:
>
> Yep, but the int2/4 functions are not used elsewhere.
The worry is more about having people invent the same stuff all over
again. If we can get a clean interface, that would ease adoption.
Hopefully.
> Overall, this leads to something like:
>
> enum { STRTOINT_OK, STRTOINT_OVERFLOW_ERROR, STRTOINT_SYNTAX_ERROR }
> pg_strto{,u}int{8?,16,32,64}
> (const char * string, const TYPE * result, const bool verbose);
Something like that. "verbose" may mean "error_ok" though. Not
having 6 times the same trailing whitespace checks and such would be
nice.
Actually, one thing which may be a problem is that we lack currently
the equivalents of pg_mul_s16_overflow and such for unsigned
integers. The point of contention comes from pgbench's
set_random_seed() in this case as we can expect an unsigned seed as
the docs say. But if we give up on the signedness of the random seed
which remains with 8 bytes, then we could let pg_strtouint64 as
backend-only and only worry about porting this set of APIs for signed
integers.
--
Michael
