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.96) (envelope-from ) id 1weyEk-005AsX-3A for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Jul 2026 16:56:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1weyEi-00F1kT-0Y for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Jul 2026 16:56:32 +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.96) (envelope-from ) id 1weyEh-00F1kL-2S for pgsql-hackers@lists.postgresql.org; Wed, 01 Jul 2026 16:56:31 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1weyEf-0000000172s-2kwI for pgsql-hackers@postgresql.org; Wed, 01 Jul 2026 16:56:30 +0000 Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-4720d22c94aso785050f8f.1 for ; Wed, 01 Jul 2026 09:56:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782924988; cv=none; d=google.com; s=arc-20260327; b=Qh8LX9W24k1lkWqR8dtn+KgGeZrP0lVkWCr3kbLsvxysciTo0KdI5LelX1ObIn+VMx Sg3SLhHdsXKBnBVlKGD9/aMhzdbVW3xBZAJpkoZldLu2gQkgPz3pQrnRw+XZpMSeXsa0 cdMTjsD4Ac+yyCWhjzrYV2ejy/tgp8Nxvb7mENNdm1++3ac+ZYp2A/auvfjYo7FXBLyr fhnI2HNirSPJy+s3bHkLYv0tNUxLt02YRdL8H+Z8paPbCaWIu8SozqK6mCXiX5G4Gvli +5lM8IuvV7uTkWg+TLgHTnyyuJHqgIjT4b8PegG8TYNqN3FW7pxaiT9FqlRjCKOHB83N WIEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=jp/z8LbFab3rHTq8iF+m6x2VHgkX4/+hOL1rbKETBWY=; fh=suEmKsyZiLO+QJ78XOp5DjG7wqfXnAG+IPR11Wyn3tQ=; b=rzz+S0af/19H7/mbfYJOLDt2F24AydU9pegTO/aHRGLRvPcZASG5lAvkRItx4c7qUn +PphRtGV+fJIfNjlsUcos4TqmZLnfxF6Ck/axijmaeiKS2L2/Q/pEPj77eMz8OFQbcw0 tsfhuuqK0Vs/SeeRIkwofMTXj49NGTlEnGkmH0qjm28xf7xro9nhswZ+BEQMGgtxQbPD 1u7YQ4YRq5buBbjlPIKgBVdWZVnErKD/jcd2z4cxuOcK5hRoJ0/xpPBw9z0ihyioTaEd T2kJmhETdBxRFR3KqVpYjQIRliC6ahWag2b4KZvkFCyXcq+M4ss8fHiRutes6G5CBXOX Svjw==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782924988; x=1783529788; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jp/z8LbFab3rHTq8iF+m6x2VHgkX4/+hOL1rbKETBWY=; b=EOlRPIhq2Vk4YxgTrCf28zf32kfYrkRMCj3yD5tzsVFlpSI8ZLlbt3ugCThlRKcjco wI2GKO+tLSLAkjbZ/w5db0OS3B1e3OM6lcYgCRvLFGxyZlZ60WFaL9W+/x+/xNENglaL GR73J7zdR2KTwcfubpqcn73bgA81gkQblg60KT/gQxX0W6DUK6QVJ1GCSzCLIUgqMfd7 1u7djPWZyPNyUScfl8MRzUdyC399zBLDM0SBXEanm6KKsTo4vfxcf+3e4bJP6gk4o0w4 uditr5NA3v+dU5n7INt48vHpmi/vJtoVK1dISOVm5Z7UuFzpFXXR2xOfAsBvKY06tD87 8tnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782924988; x=1783529788; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=jp/z8LbFab3rHTq8iF+m6x2VHgkX4/+hOL1rbKETBWY=; b=hLuDSrot2YSelPmFJxKubI3Svn58o9qj2bbKYconP1E3d8/UaNQx1cO2DSw8OSX6oX 3loiyXgUHy7iCH8nIScmC/lCKUIxycEImHe9OECadU4Nh17DL7P0ZxOhZ3OneDh/Y7US eqZQlifK45efEd5DrM46zZf7/EY9EidUpn/Z3v0tEnn+jXyHDe+HQPSd9oIn0w7SgjW8 q7UmnC08F0Iw9k3nt51ypg+b7W7CP6ri76EikUTiG9WBOKTSuBjyUqs9zYq21ShjD1EY mbQqs/aWgzSYixOOwwsYJuF0hoKuP5vxGDvrAjoabDNDXBN31jfzi0vXizGp8dGkkxxC wL9Q== X-Forwarded-Encrypted: i=1; AHgh+RrnUQwAIS2IO/RANzNcVX3aTVz3RhxHVj448csLzQzcu9Xmmn4svw2dmu+ZsR1eX1nRX8sv1oS7VysysFNW@postgresql.org X-Gm-Message-State: AOJu0YyPZXDgxesYa+PlF38+fntLXIg+eqyhJMjSYCNtg2KykGpFxXRM cnJ+XabrCd7kCRebl322vCKARlRcpCIdgHT6rcYsA4tWgSnEWLYei8cMO6GpmnjpDMEtwqAk6GU ZaZcKTiFLx7LP7hnuksNy6tyVwSdNmko= X-Gm-Gg: AfdE7ckjcsMjSAPzGkl3goBYR/gDfwylCJhbAxt+enLp3AuLAg/+Q8X3gz2Es+Bmz5T fn18261q4VlYrDJzle7rwHwZBOwVrx4/FfzMdwpvaiICf/PsvXgkjIHRFbjtt79LrJjQc6Ff2k8 FHuWJqnodozA/YeoCqYBF1Z9qVw/mdMOGilg4nkESnrY3kWqnzScWQaWQ4oB7LOiWMkCwOok51M IGwp4U5I2r7GAMTBTz+0AzanP2hWQqBWCMJKCaZ5+nlFQ0WXZb+HM7D7XjJDKp0CXPvUzYV17k8 23hDvvTf/c1M+HwkwFq/0rMU1MJVl5h724QUY8Z9LA4wvyduzpfs+Ttm7itGpaUa7JRjr2tT9G8 bowYO1kuqLqTzdWPvhVveVF/l16VIm8gPb/Su+bIIcT7+2E/9k1Y2zIsT5bGrGvgd9MhxFWU= X-Received: by 2002:a5d:56cf:0:b0:475:f0d1:eb5d with SMTP id ffacd0b85a97d-477b1b996a6mr1860871f8f.56.1782924987808; Wed, 01 Jul 2026 09:56:27 -0700 (PDT) MIME-Version: 1.0 References: <20260630173053.51.noahmisch@microsoft.com> In-Reply-To: <20260630173053.51.noahmisch@microsoft.com> From: Ashutosh Bapat Date: Wed, 1 Jul 2026 22:26:14 +0530 X-Gm-Features: AVVi8CeTTmjGOcR0f35Rwi_clFBFXkGXipxhFG7rgP-K6ZA6wawHWejqEzFW1Qs Message-ID: Subject: Re: Wrong query result w/ propgraph single lateral col reference To: Noah Misch Cc: Peter Eisentraut , pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jun 30, 2026 at 11:00=E2=80=AFPM Noah Misch wro= te: > > I had Opus 4.8 look for user-visible defects in SQL/PGQ (commit 2f094e7). > Setup: > > CREATE TABLE v (flag boolean, id int PRIMARY KEY, name text); > INSERT INTO v VALUES (true,1,'a'), (false,2,'b'), (true,3,'c'); > CREATE PROPERTY GRAPH g VERTEX TABLES (v KEY (id) LABEL l PROPERTIES (id,= flag, name)); > > Findings: > > 0. A WHERE clause that is a single lateral col reference gives wrong quer= y results: > > SELECT t.b, gt.name FROM (VALUES (false)) AS t(b), > GRAPH_TABLE (g MATCH (x IS l) WHERE t.b COLUMNS (x.name AS name)) gt; > -- got 2 rows, want 0 > > Adding "AND true" corrects the result: > > SELECT t.b, gt.name FROM (VALUES (false)) AS t(b), > GRAPH_TABLE (g MATCH (x IS l) WHERE t.b AND true COLUMNS (x.name AS nam= e)) gt; > -- got 0 rows, want 0 > > 1. A WHERE clause that is a single property reference gives a spurious er= ror: > > SELECT name FROM GRAPH_TABLE (g MATCH (x IS l) WHERE x.flag COLUMNS (x.na= me)); > -- ERROR: unrecognized node type: 63 > > Adding "AND true" again corrects the result: > > SELECT name FROM GRAPH_TABLE (g MATCH (x IS l) WHERE x.flag AND true COLU= MNS (x.name)); > -- got 2 rows, want 2 > > For (0) and (1), Opus's opinion is that the right fix is: > > --- a/src/backend/rewrite/rewriteGraphTable.c > +++ b/src/backend/rewrite/rewriteGraphTable.c > @@ replace_property_refs(Oid propgraphid, Node *node, const List *mapping= s) > context.mappings =3D mappings; > context.propgraphid =3D propgraphid; > > - return expression_tree_mutator(node, replace_property_refs_mutato= r, &context); > + return replace_property_refs_mutator(node, &context); > } > This matches the pattern in the other expression mutators, and also fixes the problems. Thanks for the report, that was quite subtle. > > 2. A property whose value is an untyped literal stays type unknown. > > CREATE PROPERTY GRAPH gu VERTEX TABLES (v KEY (id) LABEL lu PROPERTIES ('= hi' AS p)); > SELECT p FROM GRAPH_TABLE (gu MATCH (n IS lu) COLUMNS (n.p)); > -- ERROR: failed to find conversion function from unknown to text > I think property's data type should be set to text, not unknown. I think we should combine the fix for this in https://www.postgresql.org/message-id/CAHg+QDcyKNWyzDoKMxiZNjv7C-wAxs8y0ZoN= kOV137Y+nk3UXg@mail.gmail.com. > > 3. [cosmetic] Invalid DROP PROPERTIES diagnosed via internal error messag= e > > CREATE PROPERTY GRAPH g2 VERTEX TABLES ( > v KEY (id) LABEL la PROPERTIES (flag) LABEL lb PROPERTIES (name)); > ALTER PROPERTY GRAPH g2 ALTER VERTEX TABLE v ALTER LABEL la DROP PROPERTI= ES (name); > -- ERROR: could not find tuple for label property 0 > > Opus says propoid is found graph wide, but the label property oid is not > checked before performDeletion(), so the intended "label has no property" > error never fires. > This has been already reported and being discussed in [1] > > 4. [cosmetic] Duplicate property names found only via catalog unique key > > CREATE PROPERTY GRAPH g3 VERTEX TABLES (v KEY (id) LABEL lu PROPERTIES (f= lag, flag)); > -- ERROR: duplicate key value violates unique constraint "pg_propgraph_p= roperty_name_index" > > Opus thinks this is unintentional and cites lack of CommandCounterIncreme= nt() > between property inserts. We get the same error even if we split the duplicate properties across two commands. CREATE PROPERTY GRAPH g3 VERTEX TABLES (v KEY (id) LABEL lu PROPERTIES (fla= g)); alter property graph g3 alter vertex table v alter label lu add properties(flag); I think we need to check for duplicate records in pg_propgraph_label_property catalog in insert_property_record(). The function already checks for duplicate records in pg_propgraph_property. Additionally we might need CommandCounterIncrement(). [1] https://www.postgresql.org/message-id/1DA5D52A-4AFA-426E-83F7-42ED974D6= 82B@gmail.com --=20 Best Wishes, Ashutosh Bapat