Re: refactoring - share str2*int64 functions

On Fri, Oct 04, 2019 at 02:27:44PM +0530, Ashutosh Sharma wrote:
> Is there any specific reason for hard coding the *base* of a number
> representing the string in strtouint64(). I understand that currently
> strtouint64() is being used just to convert an input string to decimal
> unsigned value but what if we want it to be used for hexadecimal
> values or may be some other values, in that case it can't be used.
> Further, the function name is strtouint64() but the comments atop it's
> definition says it's pg_strtouint64(). That needs to be corrected.

Performance, as Andres has already stated upthread. Moving away from
strtol gives roughly a 40% improvement with a call-to-call comparison:
https://www.postgresql.org/message-id/20190909052814.GA26605@paquier.xyz

> At few places, I could see that the function call to
> pg_strtoint32_check() is followed by an error handling. Isn't that
> already being done in pg_strtoint32_check function itself. For e.g. in
> refint.c the function call to pg_strtoint32_check is followed by a if
> condition that checks for an error which I assume shouldn't be there
> as it is already being done by pg_strtoint32_check.

pg_strtoint32_check is used for a signed integer, so it would complain
about incorrect input syntax, but not when the parsed integer is less
or equal than 0, which is what refint.c complains about.
--
Michael