Re: libpq stricter integer parsing

Поиск
Список
Период
Сортировка
Искать
От
Fabien COELHO
Тема
Re: libpq stricter integer parsing
Дата
Msg-id
alpine.DEB.2.21.1809111851510.13887@lancre
Ответ на
Список
Дерево обсуждения
libpq stricter integer parsing Fabien COELHO <coelho@cri.ensmp.fr>
Re: libpq stricter integer parsing Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: libpq stricter integer parsing Fabien COELHO <coelho@cri.ensmp.fr>
Re: libpq stricter integer parsing Michael Paquier <michael@paquier.xyz>
Re: libpq stricter integer parsing Fabien COELHO <coelho@cri.ensmp.fr>
Re: libpq stricter integer parsing Michael Paquier <michael@paquier.xyz>
Re: libpq stricter integer parsing Fabien COELHO <coelho@cri.ensmp.fr>
Re: libpq stricter integer parsing Michael Paquier <michael@paquier.xyz>
Re: libpq stricter integer parsing Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: libpq stricter integer parsing Fabien COELHO <coelho@cri.ensmp.fr>
Re: libpq stricter integer parsing Michael Paquier <michael@paquier.xyz>

>> +   ...
>
> 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.
В списке pgsql-hackers по дате отправления
От: Andres Freund
Дата:
От: Andrew Dunstan
Дата:
FAQ