From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bug in error reporting for multi-line JSON |
Date: | 2021-01-21 18:08:28 |
Message-ID: | 914794.1611252508@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> writes:
> JSON parsing reports the line number and relevant context info
> incorrectly when the JSON contains newlines. Current code mostly just
> says "LINE 1" and is misleading for error correction. There were no
> tests for this previously.
Couple thoughts:
* I think you are wrong to have removed the line number bump that
happened when report_json_context advances context_start over a
newline. The case is likely harder to get to now, but it can still
happen can't it? If it can't, we should remove that whole stanza.
* I'd suggest naming the new JsonLexContext field "pos_last_newline";
"linefeed" is not usually the word we use for this concept. (Although
actually, it might work better if you make that point to the char
*after* the newline, in which case "last_linestart" might be the
right name.)
* I'm not enthused about back-patching. This behavior seems like an
improvement, but that doesn't mean people will appreciate changing it
in stable branches.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2021-01-21 22:16:55 | BUG #16832: Interrupted system call when working with large data tables |
Previous Message | Merlin Moncure | 2021-01-21 16:39:23 | Re: Problem with database |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2021-01-21 18:29:02 | Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit |
Previous Message | Tom Lane | 2021-01-21 17:15:56 | Re: Add primary keys to system catalogs |