Re: Fixed redundant i18n strings in json

From: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fixed redundant i18n strings in json
Date: 2014-08-07 21:26:52
Message-ID: 1407446812103-5814122.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane-2 wrote
> Robert Haas &lt;

> robertmhaas@

> &gt; writes:
>> On Sat, Aug 2, 2014 at 9:15 AM, Daniele Varrazzo
>> &lt;

> daniele.varrazzo@

> &gt; wrote:
>>> I'd definitely replace /arg/argument/. Furthermore I'd avoid the form
>>> "argument 1: something is wrong": the string is likely to end up in
>>> sentences with other colons so I'd rather use "something is wrong at
>>> argument 1".
>>>
>>> Is the patch attached better?
>
>> Looks OK to me. I thought someone else might comment, but since no
>> one has, committed.
>
> It looks to me like this is still wrong:
>
> if (nargs % 2 != 0)
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> - errmsg("invalid number or arguments: object must be
> matched key value pairs")));
> + errmsg("invalid number or arguments"),
> + errhint("Object must be matched key value pairs.")));
>
> Surely that was meant to read "invalid number OF arguments". The errhint
> is only charitably described as English, as well. I'd suggest something
> like "Arguments of json_build_object() must be pairs of keys and values."
> --- but maybe someone else can phrase that better.

The user documentation is worth emulating here:

http://www.postgresql.org/docs/9.4/interactive/functions-json.html

errmsg("argument count must be divisible by 2")
errhint("The argument list consists of alternating names and values")

Note that I s/keys/names/ to match said documentation.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Fixed-redundant-i18n-strings-in-json-tp5813330p5814122.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-08-07 21:33:10 Re: A worst case for qsort
Previous Message Rod Taylor 2014-08-07 21:23:23 Re: A worst case for qsort