Subject: [PATCH] Resolve unknown-type literals in GRAPH_TABLE COLUMNS

From: SATYANARAYANA NARLAPURAM <[email-masked]>
Date: Sat, 25 Apr 2026 12:52:44 -0700

Hi hackers,

transformRangeGraphTable() calls transformExpr() and
assign_list_collations() for COLUMNS expressions but missed calling
resolveTargetListUnknowns(). As a result, literals such as 'val1'
in a COLUMNS clause retained type "unknown", causing failures with
ORDER BY, UNION, and output conversions.

Fix by calling resolveTargetListUnknowns() on the columns target
list right after assign_list_collations(), similar to SELECT target lists
in
transformSelectStmt().

Attached a patch to fix this, which also includes test cases to reproduce.

Thanks,
Satya

---

From: Junwang Zhao <[email-masked]>
Date: Sun, 26 Apr 2026 23:10:24 +0800

Hi SATYANARAYANA,

On Sun, Apr 26, 2026 at 3:53 AM SATYANARAYANA NARLAPURAM
<[email-masked]> wrote:
> list right after assign_list_collations(), similar to SELECT target lists in
> transformSelectStmt().
>

I can reproduce this and the patch fixes it.

One question: why is resolveTargetListUnknowns called after
assign_list_collations?

I'm asking because in transformSelectStmt, resolveTargetListUnknowns
is invoked before assign_query_collations. It might not matter, but keeping
the order consistent would be good for readers.

-- 
Regards
Junwang Zhao

---

From: SATYANARAYANA NARLAPURAM <[email-masked]>
Date: Sun, 26 Apr 2026 23:04:32 -0700

Hi,

> the order consistent would be good for readers.

Updated the patch. It should be before.

Thanks,
Satya

---

From: Ashutosh Bapat <[email-masked]>
Date: Wed, 29 Apr 2026 19:39:41 +0530

> Updated the patch. It should be before.

Do we really need a test for ORDER BY on a literal column? I replaced
all the test queries with a single one which covers all the scenarios
covered by those queries.

The patch needed to consider pstate->p_resolve_unknowns. Unknown
literals are not resolved as text always. See the test query.

--
Best Wishes,
Ashutosh Bapat
From c9e6b0df945e90bb0be43c88d1c55e1ee0a9a982 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat <[email-masked]>
Date: Wed, 29 Apr 2026 19:07:13 +0530
Subject: [PATCH v20260429 5/5] Resolve unknown-type literals in GRAPH_TABLE
 COLUMNS

The unknown-type literals in the COLUMNS clause of a GRAPH_TABLE are now
resolved to the appropriate types, causing various failures. Call
resolveTargetListUnknowns() on the columns targetlist to resolve unknonw type
literals. Do this before assigning collations so that the resolved types are
used for collations assignment.

Reported by: Satya Narlapuram <[email-masked]>
Author: Satya Narlapuram <[email-masked]>
Author: Ashutosh Bapat <[email-masked]>
Reviewed by: Junwang Zhao <[email-masked]>
Discussion: https://www.postgresql.org/message-id/[email-masked]
---
 src/backend/parser/parse_clause.c         |  4 ++++
 src/test/regress/expected/graph_table.out | 11 +++++++++++
 src/test/regress/sql/graph_table.sql      |  6 ++++++
 3 files changed, 21 insertions(+)

diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index 4270c2382c4..3d0585b8efb 100644
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -1003,6 +1003,10 @@ transformRangeGraphTable(ParseState *pstate, RangeGraphTable *rgt)
 		columns = lappend(columns, te);
 	}
 
+	/* resolve any still-unresolved output columns as being type text */
+	if (pstate->p_resolve_unknowns)
+		resolveTargetListUnknowns(pstate, columns);
+
 	/*
 	 * Assign collations to column expressions now since
 	 * assign_query_collations() does not process rangetable entries.
diff --git a/src/test/regress/expected/graph_table.out b/src/test/regress/expected/graph_table.out
index 8038fcd39b7..5ef98e281e6 100644
--- a/src/test/regress/expected/graph_table.out
+++ b/src/test/regress/expected/graph_table.out
@@ -1047,4 +1047,15 @@ SELECT src.vname, count(*)
  v11   |     1
 (3 rows)
 
+-- Unknown type resolution
+SELECT c1, pg_typeof(c1), "null", pg_typeof("null") FROM
+    (SELECT *FROM GRAPH_TABLE (g1 MATCH (a IS vl1) COLUMNS ('1' AS c1, NULL as "null"))
+     UNION
+     SELECT 2, NULL);
+ c1 | pg_typeof | null | pg_typeof 
+----+-----------+------+-----------
+  1 | integer   |      | text
+  2 | integer   |      | text
+(2 rows)
+
 -- leave the objects behind for pg_upgrade/pg_dump tests
diff --git a/src/test/regress/sql/graph_table.sql b/src/test/regress/sql/graph_table.sql
index a3681c6c0ef..d3ddcdc8e20 100644
--- a/src/test/regress/sql/graph_table.sql
+++ b/src/test/regress/sql/graph_table.sql
@@ -599,4 +599,10 @@ SELECT src.vname, count(*)
                                           COLUMNS (a.vname AS n))
                        WHERE n = src.vname);
 
+-- Unknown type resolution
+SELECT c1, pg_typeof(c1), "null", pg_typeof("null") FROM
+    (SELECT *FROM GRAPH_TABLE (g1 MATCH (a IS vl1) COLUMNS ('1' AS c1, NULL as "null"))
+     UNION
+     SELECT 2, NULL);
+
 -- leave the objects behind for pg_upgrade/pg_dump tests
-- 
2.34.1

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 4 May 2026 17:12:02 +0200

> literals are not resolved as text always. See the test query.

I couldn't find a commit to apply this patch cleanly (the subject says 
patch 5/5, so maybe you had some unpublished local changes?).  After 
applying the test case manually, it looks like the test output is 
already correct without the code change.  So if this patch is still 
required, we need a better test case.

---

From: Ashutosh Bapat <[email-masked]>
Date: Tue, 12 May 2026 11:50:55 +0530

On Mon, May 4, 2026 at 8:42 PM Peter Eisentraut <[email-masked]> wrote:
> patch 5/5, so maybe you had some unpublished local changes?).

I am maintaining all the SQL/PGQ fixes in the same branch and creating
patches from that branch. Hence 5/5. But still it shouldn't have
applied cleanly. Both git cherry-pick and git am <attached patch
file>, on a fresh branch succeeded. Please let me know if you still
face the issue.

> After

Yes, the test query doesn't reproduce the bug. Actually all but only
two queries from the Satya's patch show the bug. I have included a
test query which fails, with expected error message, without code
changes now. Also I don't think we need a separate section for this
test query. Included the query in one of the earliest sections in the
file.

-- 
Best Wishes,
Ashutosh Bapat
From 69fcbf2b907ff83aaa17593c5596e495cc0720e7 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat <[email-masked]>
Date: Wed, 29 Apr 2026 19:07:13 +0530
Subject: [PATCH v20260512 4/4] Resolve unknown-type literals in GRAPH_TABLE
 COLUMNS

Reported by: Satya Narlapuram <[email-masked]>
Author: Satya Narlapuram <[email-masked]>
Author: Ashutosh Bapat <[email-masked]>
Reviewed by: Junwang Zhao <[email-masked]>
Discussion: https://www.postgresql.org/message-id/[email-masked]
---
 src/backend/parser/parse_clause.c         | 4 ++++
 src/test/regress/expected/graph_table.out | 9 +++++++++
 src/test/regress/sql/graph_table.sql      | 2 ++
 3 files changed, 15 insertions(+)

index cc6d80afd82..e8d49fd5cd4 100644
@@ -160,6 +160,15 @@ SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers) COLUMNS (c.name));
  customer3
 (3 rows)
 
+-- Unknown type resolution
+SELECT *, pg_typeof(unknown_col) AS unknown_col_type, pg_typeof(null_col) AS null_col_type FROM GRAPH_TABLE (myshop MATCH (c IS customers) COLUMNS (c.name, 'unknown-literal' AS unknown_col, NULL AS null_col));
+   name    |   unknown_col   | null_col | unknown_col_type | null_col_type 
+-----------+-----------------+----------+------------------+---------------
+ customer1 | unknown-literal |          | text             | text
+ customer2 | unknown-literal |          | text             | text
+ customer3 | unknown-literal |          | text             | text
+(3 rows)
+
 SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers WHERE c.address = 'US')-[IS customer_orders]->(o IS orders) COLUMNS (c.name));
    name    
 -----------
diff --git a/src/test/regress/sql/graph_table.sql b/src/test/regress/sql/graph_table.sql
index 0e381ec72bc..e761f09e057 100644
--- a/src/test/regress/sql/graph_table.sql
+++ b/src/test/regress/sql/graph_table.sql
@@ -134,6 +134,8 @@ INSERT INTO wishlist_items (wishlist_items_id, wishlist_id, product_no) VALUES
 
 -- single element path pattern
 SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers) COLUMNS (c.name));
+-- Unknown type resolution
+SELECT *, pg_typeof(unknown_col) AS unknown_col_type, pg_typeof(null_col) AS null_col_type FROM GRAPH_TABLE (myshop MATCH (c IS customers) COLUMNS (c.name, 'unknown-literal' AS unknown_col, NULL AS null_col));
 SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers WHERE c.address = 'US')-[IS customer_orders]->(o IS orders) COLUMNS (c.name));
 -- graph element specification without label or variable
 SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers WHERE c.address = 'US')-[]->(o IS orders) COLUMNS (c.name AS customer_name));
-- 
2.34.1