Re: libpq stricter integer parsing - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: libpq stricter integer parsing
Date
Msg-id 20180908214141.GC19122@paquier.xyz
Whole thread Raw
In response to Re: libpq stricter integer parsing  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: libpq stricter integer parsing  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Fri, Sep 07, 2018 at 11:22:14PM +0200, Fabien COELHO wrote:
> Weird indeed. However, even if the patch applied cleanly for me, it was not
> compiling anymore. Attached an updated version, in which I also tried to
> improve the error message on trailing garbage.

At least now it applies for me, thanks.

+    Integer values expected for keywords <literal>port</literal>,
+    <literal>connect_timeout</literal>,
+    <literal>keepalives_idle</literal>,
+    <literal>keepalives_interval</literal> and
+    <literal>keepalives_timeout</literal> are parsed strictly.
Wouldn't it be better to actually document what "parsed strictly" means?

A wild though: we already have things like pg_strtoint32 or pg_atoi
which do similar error handling in smarter ways.  Wouldn't we want to
refactor the code so as libpq makes use of such routines?  This would
mean that the error string should be moved around, and allowing
frontends to use those utilities requires some extra engineering.

Not that this patch should reinvent the world...
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Prevent concurrent DROP SCHEMA when certain objects are beinginitially created in the namespace
Next
From: John Naylor
Date:
Subject: Re: Allow to specify a index name as ANALYZE parameter