From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon.riggs@enterprisedb.com>
cc: pgsql-bugs@postgresql.org
Subject: Re: Bug in error reporting for multi-line JSON
In-reply-to: 
 <CANbhV-EPBnXm3MF_TTWBwwqgn1a1Ghmep9VHfqmNBQ8BT0f+_g@mail.gmail.com>
References: 
 <CANbhV-EPBnXm3MF_TTWBwwqgn1a1Ghmep9VHfqmNBQ8BT0f+_g@mail.gmail.com>
Comments: In-reply-to Simon Riggs <simon.riggs@enterprisedb.com>
	message dated "Wed, 20 Jan 2021 06:58:09 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <914793.1611252508.1@sss.pgh.pa.us>
Date: Thu, 21 Jan 2021 13:08:28 -0500
Message-ID: <914794.1611252508@sss.pgh.pa.us>
Precedence: bulk

Simon Riggs <simon.riggs@enterprisedb.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