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.
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.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Wed, Sep 18, 2019 at 6:43 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Sep 17, 2019 at 11:29:13AM +0900, Michael Paquier wrote:
> > In order to unify the parsing interface and put all the conversion
> > routines in a single place, I still think that the patch has value so
> > I would still keep it (with a fix for the queryId parsing of course),
> > but there is much more to it.
>
> As of now, here is an updated patch which takes the path to not
> complicate the refactored APIs and fixes the issue with queryID in
> readfuncs.c. Thoughts?
> --
> Michael