Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s2rUZ-006pQq-Cr for pgsql-hackers@arkaria.postgresql.org; Fri, 03 May 2024 11:54:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s2rUW-008f3j-KD for pgsql-hackers@arkaria.postgresql.org; Fri, 03 May 2024 11:54:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s2rUW-008f3a-AF for pgsql-hackers@lists.postgresql.org; Fri, 03 May 2024 11:54:17 +0000 Received: from fout6-smtp.messagingengine.com ([103.168.172.149]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s2rUU-001EgT-MK for pgsql-hackers@postgresql.org; Fri, 03 May 2024 11:54:15 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id CD0811380584; Fri, 3 May 2024 07:54:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 03 May 2024 07:54:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eisentraut.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm2; t=1714737253; x=1714823653; bh=iVAcuDusjY9ROUY2PHUCXcrrh61p14Ts 4L3ryPxd8+s=; b=KxnmD57szWRTOREzM0t+c8stnopbqQK8jOPwRaaee2WbXYzU rIkWM84XG1njY5ghE6ToNxKFwKQ7DuOH7fxHHX+242YCHNUPHKzumwy9xj2DlimO UZHPECmQWJ0joUcJH3SO1ZPl8YTTUt8FWMoTObZczdOFR4gDqmvhcWE3MJToh54m Yj4V9INH1See8GwuQqCwQarjg70PUXV47d+1B9sFVQBhSiNEJ695AzxHLeNoBTA3 6Z0qbPggdEd/8j/ehMBWgVQSSGtgyupREAmCl2s+BAC1/9/hGmtSlLLtymEgq6R7 Lr04ENnp05hqpkQbcEC5sWKGbS3cW1PgbJY1bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1714737253; x= 1714823653; bh=iVAcuDusjY9ROUY2PHUCXcrrh61p14Ts4L3ryPxd8+s=; b=C LLFHnH+hZ3/xkdytil3rPQERuttkL4tMscZ/bvIowwTHR2P8E2lGk89F6nXjIno0 DtuX//T6tf95R+A8ej0dVnko1NUwMBnnittBiRpRthGSzvFPoKS/DKeGK4CdmaAM rixtNbj4MTZu3ChpEOATf948duCZNQ2DUQ2WLvFhuLJB9QFlBY78CW8fDDXsw/r2 LNkOfmyn0+JOJQw3lvpVpRtxcm9Bg1OkyAzNlQ+1rqe9dypn4hXy+gX/rUQsGYE6 GEudo+HE6QGseaa3S8WaP86AElm2DZB3Ckab6kyy3Q3HI9cHEnflr7pVHYH+a2j0 jaK1ArGYv3z2aCWaTsq0w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvddvtddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrsegvihhsvghnthhrrghuthdrohhrgh eqnecuggftrfgrthhtvghrnhepgfejtdfhkeeftdeugfeileehteeljeeghfeuledthfeu tedvffdukeefjefhgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepphgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhg X-ME-Proxy: Feedback-ID: ie0a040ee:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 3 May 2024 07:54:12 -0400 (EDT) Message-ID: Date: Fri, 3 May 2024 13:54:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] json_lex_string: don't overread on bad UTF8 To: Jacob Champion , PostgreSQL Hackers Cc: Andrew Dunstan References: Content-Language: en-US From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 30.04.24 19:39, Jacob Champion wrote: > Tangentially: Should we maybe rethink pieces of the json_lex_string > error handling? For example, do we really want to echo an incomplete > multibyte sequence once we know it's bad? I can't quite find the place you might be looking at in json_lex_string(), but for the general encoding conversion we have what would appear to be the same behavior in report_invalid_encoding(), and we go out of our way there to produce a verbose error message including the invalid data.