From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: libpq stricter integer parsing |
Date: | 2018-09-11 17:03:41 |
Message-ID: | alpine.DEB.2.21.1809111851510.13887@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> + <para>...</para>
>
> I would leave this out. We don't need to document every single
> refinement of parsing rules. This might better belong in the release notes.
Why not, I'd be fine with that. The fact that the libpq parser was quite
fuzzy was not documented, the behavior was really a side effect of the
implementation which never suggested that it would work.
>> + appendPQExpBuffer(&conn->errorMessage,
>> + libpq_gettext("invalid value for keyword \"%s\"\n"),
>> + context);
>
> Add the actual invalid value to the error message.
Indeed.
Attached Michael's simplified version updated with your remarks.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
libpq-strict-atoi-4.patch | text/x-diff | 3.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-09-11 20:13:15 | Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c) |
Previous Message | Andres Freund | 2018-09-11 16:51:36 | Re: StandbyAcquireAccessExclusiveLock doesn't necessarily |