Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 13, 2012 at 1:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> ! 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
>> }
>> ]
> Hmm. If your plan is to trace back to the opening brace you were
> expecting to match, I don't think that's going to work either. What
> if there are three pages (or 3MB) of data in between?
No, that's not the proposal; I only anticipate printing a few dozen
characters of context. But that could still mean printing something
like
DETAIL: expected "," or "}", but found "]".CONTEXT: JSON data, line 123: ..."bar":44 } ]
which I argue is much more useful than just seeing the "]". So the
question is whether it's still as useful if we mangle the whitespace.
I'm thinking it's not. We don't mangle whitespace when printing SQL
statements into the log, anyway.
regards, tom lane