Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
Дата
Msg-id 12857.1339607071@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I like some of these changes - in particular, the use of errcontext(),
> but some of them still seem off.

> ! DETAIL:  Token "'" is invalid.
> ! CONTEXT:  JSON data, line 1: '...

> This doesn't make sense to me.

Well, the input is two single quotes and the complaint is that the first
one of them doesn't constitute a valid JSON token.  What would you
expect to see instead?

I considered putting double quotes around the excerpt text, but we do
not do that in SQL error-context reports, and it seems likely to just be
confusing given the prevalence of double quotes in JSON data.  But happy
to consider opposing arguments.

Another thing that could be done here is to print the rest of the line,
rather than "...", if there's not very much of it.  I'm not sure that's
an improvement though.  The advantage of the proposed design is that the
point where the excerpt ends is exactly where the error was detected;
lacking an error cursor, I don't see how else to present that info.

> ! DETAIL:  Character with value 0x0a must be escaped.
> ! CONTEXT:  JSON data, line 1: "abc
> ! ...

> This seems an odd way to present this, especially if the goal is to
> NOT include the character needing escaping in the log unescaped, which
> I thought was the point of saying 0x0a.

Do you think it would be better to present something that isn't what the
user typed?  Again, I don't see an easy improvement here.  If you don't
want newlines in the logged context, what will we do for something like
{"foo": {    "bar":44    }]

There basically isn't any useful context to present unless we are
willing to back up several lines, and I don't think it'll be more
readable if we escape all the newlines.

> ! DETAIL:  "\u" must be followed by four hexadecimal digits.
> ! CONTEXT:  JSON data, line 1: "\u000g...

> Why does this end in ... even though there's nothing further in the
> input string?

There is something further, namely the trailing double quote.

The examples in the regression tests are not really designed to show
cases where this type of error reporting is an improvement, because
there's hardly any context around the error sites.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: initdb and fsync
Следующее
От: Steve Singer
Дата:
Сообщение: Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture