Re: libpq stricter integer parsing

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq stricter integer parsing
Date: 2018-09-08 21:41:41
Message-ID: 20180908214141.GC19122@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2018-09-09 06:25:49 Re: Allow to specify a index name as ANALYZE parameter
Previous Message Michael Paquier 2018-09-08 21:09:31 Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace