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.98.2) (envelope-from ) id 1xHwZm-00000003Ndv-0y0y for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Oct 2026 05:03:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHwZj-0000000H5F3-06zT for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Oct 2026 05:03:19 +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.98.2) (envelope-from ) id 1xHqlY-0000000GHCu-47c0 for pgsql-bugs@lists.postgresql.org; Fri, 16 Oct 2026 22:51:08 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xHqlV-00000002PQs-3UCQ for pgsql-bugs@lists.postgresql.org; Fri, 16 Oct 2026 22:51:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=oK8HWD+EUihYjQfg7fj0fwj1WHhY3eY93uN9e1FepIc=; b=237JTqNeT+58XBQ2LLBR/IzR1T xacpwZR19nOh2zavWCg8WvddwoRefZ8urOnXnB0RX7Me+9kXc/LtII5ifnyNTpj5I26NkNdBnnTy7 wum1DbWIWplZHevlsUjbuLljmkUK0fkktgYahzG332FMpdytVJ0M78W8Q6J+p42M0GEGX06YBEFlr RzczGAjI01nyyXFxyaVA4hXnvk1sAW+lBkE0UowjUn2DzcPbaYkCNW1nNHwG7LriBQXqB7c6o2bf2 8qkRWnxAwRxP0Nk5yp4t7ateAqcTMNC83vQBQ8P5ahX2DcRLUk91I6pHbLWQ+wClql2B4ebQbuBz4 v3Zz9cPA==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xHqlU-00000006wbF-3Xj8 for pgsql-bugs@lists.postgresql.org; Fri, 16 Oct 2026 22:51:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHqlT-00000003k3Q-29fI for pgsql-bugs@lists.postgresql.org; Fri, 16 Oct 2026 22:51:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19768: JSON_TABLE: row/text comparisons in context item or PASSING give wrong results or spurious collation To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: venu2805k@gmail.com Reply-To: venu2805k@gmail.com, pgsql-bugs@lists.postgresql.org Date: Fri, 16 Oct 2026 22:51:01 +0000 Message-ID: <19768-3633daa830be95db@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19768 Logged by: Venu Kummari Email address: venu2805k@gmail.com PostgreSQL version: 18.6 Operating system: Linux x86_64 Description: =20 PostgreSQL versions: 17.11, 18.6, master (26bd08f). Tested from source on Linux x86_64. The JSON_TABLE context-item expression fails to assign collations correctly, causing incorrect results for row comparisons and collation errors for valid text comparisons. 1. Incorrect result / assertion failure: SELECT * FROM JSON_TABLE( jsonb_build_object('k', ROW(1, 2) < ROW(3, 4)), '$' COLUMNS (a bool PATH '$.k') ); Expected: t Actual: f on PostgreSQL 17.11 and 18.6. On an assertion-enabled master build, the backend fails with: TRAP: failed Assert("list_length(rcexpr->inputcollids) =3D=3D nopers"), Fil= e: "execExpr.c", Line: 2078 2. Collation error in the context item: SELECT * FROM JSON_TABLE( jsonb_build_object('k', 'a' < 'b' COLLATE "C"), '$' COLUMNS (a bool PATH '$.k') ); Expected: t Actual: ERROR: could not determine which collation to use for string comparison 3. Collation error in a PASSING argument: SELECT * FROM JSON_TABLE( jsonb '{}', '$' PASSING 'a' < 'b' COLLATE "C" AS x COLUMNS (a bool PATH '$x') ); This also fails with "could not determine which collation to use for string comparison", despite the explicit COLLATE clause. The same expressions work outside JSON_TABLE. Suspected cause: transformJsonTable() in src/backend/parser/parse_jsontable.c does not call assign_expr_collations() for the context-item expression and PASSING arguments. The corresponding XMLTABLE transformation performs collation assignment, as do JSON_TABLE column expressions. Without the required collation information, a RowCompareExpr can have an empty inputcollids list, causing the executor to compare zero columns and return an incorrect result. A proposed patch adds the missing collation assignment and regression tests. The patch was tested on master, and the core regression suite passed (239/239 tests). The source change applies to REL_17_STABLE and REL_18_STABLE. The bug was discovered through grammar-based fuzzing.