Re: refactoring - share str2*int64 functions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: refactoring - share str2*int64 functions
Date
Msg-id 20190719032127.GH1859@paquier.xyz
Whole thread Raw
In response to Re: refactoring - share str2*int64 functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: refactoring - share str2*int64 functions  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Jul 18, 2019 at 07:57:41AM +0000, Fabien COELHO wrote:
> I'm unhappy with the function names though, feel free to improve.

I would have something rather close to what you are suggesting, still
not exactly that because we just don't care about the error strings
generated for the frontend.  And my bet is that each frontend would
like to have their own error message depending on the error case.

FWIW, I had a similar experience with pg_strong_random() not so long
ago, which required a backend-specific handling because the fallback
random implementation needed some tweaks at postmaster startup (that's
why we have an alias pg_backend_random in include/port.h).  So I would
recommend the following, roughly:
- One set of functions in src/port/ which return the status code for
the error handling, without any error reporting in it to avoid any
ifdef FRONTEND business, which have a generic name pg_strto[u]intXX
(XX = {16,32,64}).  And have all that in a new, separate file, say
strtoint.c?
- One set of functions for the backend, called pg_stro[u]intXX_backend
or pg_backend_stro[u]intXX which can take as extra argument error_ok,
calling the portions in src/port/, and move those functions in a new
file prefixed with "backend_" in src/backend/utils/misc/ with a name
consistent with the one in src/port/ (with the previous naming that
would be backend_strtoint.c)
- We also need the unsigned-specific equivalents of
pg_mul_s64_overflow and such, so I would suggest putting that in a new
header, simply uint.h.  If I finish by committing this stuff, I would
handle that in a separate commit.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: sepgsql seems rather thoroughly broken on Fedora 30
Next
From: Michael Paquier
Date:
Subject: On the stability of TAP tests for LDAP