Hello Thomas,
> +extern bool pg_strtoint64(const char *str, bool errorOK, int64 *result);
> +extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
>
> One of these things is not like the other.
Indeed.
I agree that it is unfortunate, and it was bothering me a little as well.
> Let's see... the int64 version is used only by pgbench and is being
> promoted to common where it can be used by more code.
No and yes.
The pgbench code was a copy of server-side internal "scanint8", so it is
used both by pgbench and the server-side handling of "int8", it is used
significantly, taking advantage of its versatile error reporting feature
on both sides.
> With a name like that, wouldn't it make sense to bring it into line with
> the uint64 interface, and then move pgbench's error reporting stuff back
> into pgbench?
That would need moving the server-side error handling as well, which I
would not really be happy with.
> The uint64 one derives its shape from the family of standard functions
> like strtol() so I think it wins.
Yep, it cannot be changed either.
I do not think that changing the error handling capability is appropriate,
it is really a feature of the function. The function could try to use an
internal pg_strtoint64 which would look like the other unsigned version,
but then it would not differentiate the various error conditions (out of
range vs syntax error).
The compromise I can offer is to change the name of the first one, say to
"pg_scanint8" to reflect its former backend name. Attached a v4 which does
a renaming so as to avoid the name similarity but signature difference. I
also made both error messages identical.
--
Fabien.
