Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lGqQf-00073d-31 for pgsql-bugs@arkaria.postgresql.org; Mon, 01 Mar 2021 21:50:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lGqQd-0002nU-RD for pgsql-bugs@arkaria.postgresql.org; Mon, 01 Mar 2021 21:50:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lGqQd-0002lw-LH for pgsql-bugs@lists.postgresql.org; Mon, 01 Mar 2021 21:50:11 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lGqQX-0007DU-Fv for pgsql-bugs@postgresql.org; Mon, 01 Mar 2021 21:50:10 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 121Lo1lO849058; Mon, 1 Mar 2021 16:50:02 -0500 From: Tom Lane To: Daniel Gustafsson cc: Hamid Akhtar , Simon Riggs , pgsql-bugs@postgresql.org Subject: Re: Bug in error reporting for multi-line JSON In-reply-to: <01F48B70-5CAA-4922-B900-80E49A2D8488@yesql.se> References: <914794.1611252508@sss.pgh.pa.us> <01F48B70-5CAA-4922-B900-80E49A2D8488@yesql.se> Comments: In-reply-to Daniel Gustafsson message dated "Mon, 01 Mar 2021 15:04:40 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <849056.1614635401.1@sss.pgh.pa.us> Date: Mon, 01 Mar 2021 16:50:01 -0500 Message-ID: <849057.1614635401@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Daniel Gustafsson writes: > I'm changing the status of this patch to Ready for Committer. I reviewed this and pushed it, with some changes. I noted that there was a basically unused "line_start" field in JsonLexContext, which seems clearly to have been meant to track what the new field was going to track. So we can fix this without any new field by updating that at the right times. I thought putting jsonb tests into json.sql was a bit poorly thought out. I ended up adding parallel tests to both json.sql and jsonb.sql ... maybe that's overkill, but a lot of the rest of those scripts is duplicative too. The tests weren't exercising the dots-at-start-of-line behavior, either. regards, tom lane