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.ga26...@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
signature.asc
Description: PGP signature
