public inbox for [email protected]  
help / color / mirror / Atom feed
[PATCH] Improve error message for graph variable references in subqueries within GRAPH_TABLE
2+ messages / 2 participants
[nested] [flat]

* [PATCH] Improve error message for graph variable references in subqueries within GRAPH_TABLE
@ 2026-04-25 17:11  SATYANARAYANA NARLAPURAM <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: SATYANARAYANA NARLAPURAM @ 2026-04-25 17:11 UTC (permalink / raw)
  To: PostgreSQL Hackers <[email protected]>

Hi Hackers,

When a subquery inside GRAPH_TABLE COLUMNS or MATCH WHERE references a
graph pattern variable, the error was a confusing "missing FROM-clause
entry for table".  Fix by walking the parentParseState chain in
transformGraphTablePropertyRef() to detect the graph variable and report
a clear "cannot be used in a subquery" error instead.


Based on the below comment and code in  transformRangeGraphTable I am
assuming we don't support
subqueries for now.

  /*
* If we support subqueries within GRAPH_TABLE, those need to be
* propagated to the queries resulting from rewriting graph table RTE. We
* don't do that right now, hence prohibit it for now.
*/
if (pstate->p_hasSubLinks)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("subqueries within GRAPH_TABLE reference are not supported")));
pstate->p_hasSubLinks = saved_hasSublinks;

Attached a patch to address this which also includes a test.

Thanks,
Satya


Attachments:

  [application/octet-stream] 0001-Improve-error-for-graph-variable-references-in-subqu.patch (5.0K, 3-0001-Improve-error-for-graph-variable-references-in-subqu.patch)
  download | inline diff:
From ce448a1b559b5a3b68a78e226277451ef76cb095 Mon Sep 17 00:00:00 2001
From: Satya Narlapuram <[email protected]>
Date: Sat, 25 Apr 2026 16:43:33 +0000
Subject: [PATCH] Improve error message for graph variable references in subqueries
 within GRAPH_TABLE

When a subquery inside GRAPH_TABLE COLUMNS or MATCH WHERE references a
graph pattern variable, the error was a confusing "missing FROM-clause
entry for table".  Fix by walking the parentParseState chain in
transformGraphTablePropertyRef() to detect the graph variable and report
a clear "cannot be used in a subquery" error instead.
---
 src/backend/parser/parse_graphtable.c     | 28 +++++++++++++++++++++++
 src/test/regress/expected/graph_table.out | 15 ++++++++++++
 src/test/regress/sql/graph_table.sql      | 11 +++++++++
 3 files changed, 54 insertions(+)

diff --git a/src/backend/parser/parse_graphtable.c b/src/backend/parser/parse_graphtable.c
index 73fbfb54..5e5da5bc 100644
--- a/src/backend/parser/parse_graphtable.c
+++ b/src/backend/parser/parse_graphtable.c
@@ -81,7 +81,35 @@ transformGraphTablePropertyRef(ParseState *pstate, ColumnRef *cref)
 	GraphTableParseState *gpstate = pstate->p_graph_table_pstate;
 
 	if (!gpstate)
+	{
+		/*
+		 * No GRAPH_TABLE context in this ParseState; may be inside a
+		 * subquery whose sub-ParseState doesn't inherit p_graph_table_pstate.
+		 * Walk up the parent chain to detect graph variable references and
+		 * report a clear error instead of "missing FROM-clause entry".
+		 */
+		if (list_length(cref->fields) == 2)
+		{
+			Node	   *field1 = linitial(cref->fields);
+
+			if (!IsA(field1, A_Star))
+			{
+				for (ParseState *ps = pstate->parentParseState;
+					 ps != NULL;
+					 ps = ps->parentParseState)
+				{
+					if (ps->p_graph_table_pstate &&
+						list_member(ps->p_graph_table_pstate->variables, field1))
+						ereport(ERROR,
+								(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+								 errmsg("graph pattern variable reference \"%s\" cannot be used in a subquery",
+										strVal(field1)),
+								 parser_errposition(pstate, cref->location)));
+				}
+			}
+		}
 		return NULL;
+	}
 
 	if (list_length(cref->fields) == 2)
 	{
diff --git a/src/test/regress/expected/graph_table.out b/src/test/regress/expected/graph_table.out
index a2d7cdf3..d3c20610 100644
--- a/src/test/regress/expected/graph_table.out
+++ b/src/test/regress/expected/graph_table.out
@@ -1032,6 +1032,21 @@ SELECT sname, dname FROM GRAPH_TABLE (g1 MATCH (src)->(dest) WHERE src.vprop1 >
 ERROR:  subqueries within GRAPH_TABLE reference are not supported
 SELECT sname, dname FROM GRAPH_TABLE (g1 MATCH (src)->(dest) WHERE out_degree(src.vname) > (SELECT max(out_degree(nname)) FROM GRAPH_TABLE (g1 MATCH (node) COLUMNS (node.vname AS nname))) COLUMNS(src.vname AS sname, dest.vname AS dname));
 ERROR:  subqueries within GRAPH_TABLE reference are not supported
+-- subquery referencing graph variable in COLUMNS (should report clear error)
+SELECT * FROM GRAPH_TABLE (g1 MATCH (src IS vl1)
+  COLUMNS (src.vname AS sname,
+           (SELECT count(*) FROM v1 WHERE vprop1 = src.vprop1) AS cnt)) gt;
+ERROR:  graph pattern variable reference "src" cannot be used in a subquery
+LINE 3: ...          (SELECT count(*) FROM v1 WHERE vprop1 = src.vprop1...
+                                                             ^
+-- EXISTS subquery referencing graph variable in MATCH WHERE
+SELECT * FROM GRAPH_TABLE (g1
+  MATCH (src IS vl1 WHERE EXISTS (
+    SELECT 1 FROM v1 WHERE vprop1 = src.vprop1))
+  COLUMNS (src.vname AS sname)) gt;
+ERROR:  graph pattern variable reference "src" cannot be used in a subquery
+LINE 3:     SELECT 1 FROM v1 WHERE vprop1 = src.vprop1))
+                                            ^
 -- GRAPH_TABLE subquery in HAVING clause
 SELECT src.vname, count(*)
   FROM v1 AS src
diff --git a/src/test/regress/sql/graph_table.sql b/src/test/regress/sql/graph_table.sql
index b054dbdf..2521c4ca 100644
--- a/src/test/regress/sql/graph_table.sql
+++ b/src/test/regress/sql/graph_table.sql
@@ -590,6 +590,17 @@ SELECT * FROM customers co WHERE co.customer_id = (SELECT customer_id FROM GRAPH
 SELECT sname, dname FROM GRAPH_TABLE (g1 MATCH (src)->(dest) WHERE src.vprop1 > (SELECT max(v1.vprop1) FROM v1) COLUMNS(src.vname AS sname, dest.vname AS dname));
 SELECT sname, dname FROM GRAPH_TABLE (g1 MATCH (src)->(dest) WHERE out_degree(src.vname) > (SELECT max(out_degree(nname)) FROM GRAPH_TABLE (g1 MATCH (node) COLUMNS (node.vname AS nname))) COLUMNS(src.vname AS sname, dest.vname AS dname));
 
+-- subquery referencing graph variable in COLUMNS (should report clear error)
+SELECT * FROM GRAPH_TABLE (g1 MATCH (src IS vl1)
+  COLUMNS (src.vname AS sname,
+           (SELECT count(*) FROM v1 WHERE vprop1 = src.vprop1) AS cnt)) gt;
+
+-- EXISTS subquery referencing graph variable in MATCH WHERE
+SELECT * FROM GRAPH_TABLE (g1
+  MATCH (src IS vl1 WHERE EXISTS (
+    SELECT 1 FROM v1 WHERE vprop1 = src.vprop1))
+  COLUMNS (src.vname AS sname)) gt;
+
 -- GRAPH_TABLE subquery in HAVING clause
 SELECT src.vname, count(*)
   FROM v1 AS src
-- 
2.43.0



^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: [PATCH] Improve error message for graph variable references in subqueries within GRAPH_TABLE
@ 2026-04-29 14:00  Ashutosh Bapat <[email protected]>
  parent: SATYANARAYANA NARLAPURAM <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Ashutosh Bapat @ 2026-04-29 14:00 UTC (permalink / raw)
  To: SATYANARAYANA NARLAPURAM <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>

On Sat, Apr 25, 2026 at 10:42 PM SATYANARAYANA NARLAPURAM
<[email protected]> wrote:
>
> Hi Hackers,
>
> When a subquery inside GRAPH_TABLE COLUMNS or MATCH WHERE references a
> graph pattern variable, the error was a confusing "missing FROM-clause
> entry for table".  Fix by walking the parentParseState chain in
> transformGraphTablePropertyRef() to detect the graph variable and report
> a clear "cannot be used in a subquery" error instead.
>
>
> Based on the below comment and code in  transformRangeGraphTable I am assuming we don't support
> subqueries for now.
>
>   /*
> * If we support subqueries within GRAPH_TABLE, those need to be
> * propagated to the queries resulting from rewriting graph table RTE. We
> * don't do that right now, hence prohibit it for now.
> */
> if (pstate->p_hasSubLinks)
> ereport(ERROR,
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> errmsg("subqueries within GRAPH_TABLE reference are not supported")));
> pstate->p_hasSubLinks = saved_hasSublinks;

We don't support subqueries in GRAPH_TABLE for now.

However, I don't think this is the right fix. Consider a query like

SELECT * FROM GRAPH_TABLE (g1 MATCH (src IS vl1)
COLUMNS (src.vname AS sname,
(SELECT * FROM t1 src WHERE a > (SELECT count(*) FROM v1 WHERE vprop1
= src.vprop1) AS cnt))) gt;

The src referenced in the innermost subquery should be resolved to the
t1 in its outer query. That will happen when the column reference
walks the parser state stack. However, since we call
transformGraphPropertyRef() before trying to resolve a column ref as a
column ref, your changes will throw a premature error "graph pattern
variable reference \"%s\" cannot be used in a subquery". I don't think
that's right. A better fix might be to detect a subquery within
GRAPH_TABLE before transforming the subquery and throw "subqueries
within GRAPH_TABLE reference are not supported" error there. That may
be tricky to do, since parse states created between the parse state
which has graph state and parse state of the subquery all have to
carry a flag indicating the existence of a graph table somewhere up
the stack.

-- 
Best Wishes,
Ashutosh Bapat





^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2026-04-29 14:00 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-25 17:11 [PATCH] Improve error message for graph variable references in subqueries within GRAPH_TABLE SATYANARAYANA NARLAPURAM <[email protected]>
2026-04-29 14:00 ` Ashutosh Bapat <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox