pgsql: Improve error messages for bytea decoding failures.

Robert Haas <rhaas@postgresql.org> writes:

Improve error messages for bytea decoding failures.

Per style guide, errhints should be capitalized full sentences, ie

- errhint("input data is missing padding, truncated, or otherwise corrupted")));
+ errhint("Input data is missing padding, truncated, or otherwise corrupted.")));

Also, it's unwise to use %c on a value you aren't sure is an ASCII
character; that's likely to produce an invalidly-encoded error message,
which will *not* be an improvement of the user experience.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On Wed, Jul 9, 2014 at 11:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <rhaas@postgresql.org> writes:

Improve error messages for bytea decoding failures.

Per style guide, errhints should be capitalized full sentences, ie

- errhint("input data is missing padding, truncated, or otherwise corrupted")));
+ errhint("Input data is missing padding, truncated, or otherwise corrupted.")));

Oops.

Also, it's unwise to use %c on a value you aren't sure is an ASCII
character; that's likely to produce an invalidly-encoded error message,
which will *not* be an improvement of the user experience.

Yeah, I was a little worried about that. But I noticed that in the
same file we already had this:

ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("invalid hexadecimal digit: \"%c\"", c)));

So I figured it must be OK. If it's not, we should fix both places.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers