Re: refactoring - share str2*int64 functions

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: refactoring - share str2*int64 functions
Date: 2019-07-17 08:29:58
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.

> Overall, this leads to something like:
> 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

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2019-07-17 08:34:45 Re: [PATCH] Make configuration file "include" directive handling more robust
Previous Message Iwata, Aya 2019-07-17 08:12:50 RE: libpq debug log