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 1o8YUY-0008Qm-Ml for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jul 2022 02:40:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o8YUX-0005A1-IU for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jul 2022 02:40:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8YUX-00059p-9d for pgsql-hackers@lists.postgresql.org; Tue, 05 Jul 2022 02:40:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8YUU-0006Tw-Vc for pgsql-hackers@lists.postgresql.org; Tue, 05 Jul 2022 02:40:44 +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 2652efj41809333; Mon, 4 Jul 2022 22:40:41 -0400 From: Tom Lane To: Justin Pryzby cc: pgsql-hackers@lists.postgresql.org Subject: Re: Bugs in copyfuncs/equalfuncs support for JSON node types In-reply-to: <20220705021857.GO13040@telsasoft.com> References: <1794155.1656984188@sss.pgh.pa.us> <20220705021857.GO13040@telsasoft.com> Comments: In-reply-to Justin Pryzby message dated "Mon, 04 Jul 2022 21:18:57 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1809331.1656988841.1@sss.pgh.pa.us> Date: Mon, 04 Jul 2022 22:40:41 -0400 Message-ID: <1809332.1656988841@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Justin Pryzby writes: > Do the missing fields indicate a deficiency in test coverage ? > _copyJsonTablePlan.pathname and _equalJsonTable.plan. Yeah, I'd say so, but I think constructing a test case to prove it's broken might be more trouble than it's worth --- particularly seeing that we're about to automate this stuff. Because of that, I wouldn't even be really concerned about these bugs in HEAD; but this needs to be back-patched into v15. The existing COPY_PARSE_PLAN_TREES logic purports to test this area, but it fails to notice these bugs for a few reasons: * JsonTable.lateral: COPY_PARSE_PLAN_TREES itself failed to detect this problem because of matching omissions in _copyJsonTable and _equalJsonTable. But the lack of any follow-on failure implies that we don't have any test cases where the lateral flag is significant. Maybe that means the field is useless? This one would be worth a closer look, perhaps. * JsonTableColumn.format: this scalar-instead-of-deep-copy bug would only be detectable if you were able to clobber the original parse tree after copying. I have no ideas about an easy way to do that. It'd surely bite somebody in the field someday, but making a reproducible test is way harder. * JsonTable.plan: to detect the missed comparison, you'd have to build a test case where comparing two such trees actually made a visible difference; which would require a fair amount of thought I fear. IIUC this node type will only appear down inside jointrees, which we don't usually do comparisons on. regards, tom lane