Fix GRAPH TABLE label and property error reporting

On Tue, Aug 18, 2026 at 9:16 PM Sami Imseih <samimseih@gmail.com> wrote:

Hi,

While looking at GRAPH_TABLE parsing, I found that in
transformGraphTablePropertyRef(), a property reference whose name does
not exist in the property graph is reported with ERRCODE_SYNTAX_ERROR:

```
pgptup = SearchSysCache2(PROPGRAPHPROPNAME, ...);
if (!HeapTupleIsValid(pgptup))
ereport(ERROR,
errcode(ERRCODE_SYNTAX_ERROR),
errmsg("property \"%s\" does not exist", propname));
```

Unlike the A_Star cases just above, which are genuine syntax errors, here
the statement parses fine but the property does not resolve. It should use
ERRCODE_UNDEFINED_OBJECT. The unknown label check in
transformLabelExpr() already does this, so these should be consistent.

I don't have access to SQL/PGQ standard right now, but I think this
error has been specified as a syntax error in the standard. Will
confirm once I have access to it.

ERRCODE_UNDEFINED_COLUMN could also fit, but a property is an object of
the graph, not a column of a relation, so I went with UNDEFINED_OBJECT to
match the label check. Maybe others have a different opinion on the exact
code, but this clearly should not be a syntax error.

While at it, neither the property nor the label lookup supplied an error
position. The attached patch adds one to both.

I think that's desirable. Will review the code soon.

--
Best Wishes,
Ashutosh Bapat

On Wed, Aug 19, 2026 at 6:54 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:

On Tue, Aug 18, 2026 at 9:16 PM Sami Imseih <samimseih@gmail.com> wrote:

Hi,

While looking at GRAPH_TABLE parsing, I found that in
transformGraphTablePropertyRef(), a property reference whose name does
not exist in the property graph is reported with ERRCODE_SYNTAX_ERROR:

```
pgptup = SearchSysCache2(PROPGRAPHPROPNAME, ...);
if (!HeapTupleIsValid(pgptup))
ereport(ERROR,
errcode(ERRCODE_SYNTAX_ERROR),
errmsg("property \"%s\" does not exist", propname));
```

Unlike the A_Star cases just above, which are genuine syntax errors, here
the statement parses fine but the property does not resolve. It should use
ERRCODE_UNDEFINED_OBJECT. The unknown label check in
transformLabelExpr() already does this, so these should be consistent.

I don't have access to SQL/PGQ standard right now, but I think this
error has been specified as a syntax error in the standard. Will
confirm once I have access to it.

ERRCODE_UNDEFINED_COLUMN could also fit, but a property is an object of
the graph, not a column of a relation, so I went with UNDEFINED_OBJECT to
match the label check. Maybe others have a different opinion on the exact
code, but this clearly should not be a syntax error.

I was wrong. It's not specified in the syntax rules. Your change is
correct. In fact transformLabelExpr() does use
ERRCODE_UNDEFINED_OBJECT for missing labels. I also agree with your
reasoning behind not using ERRCODE_UNDEFINED_COLUMN.

Additionally the property does not exist message should also mention
the property graph name in case there are multiple property graph
references in the query. Can you please add that change.

While at it, neither the property nor the label lookup supplied an error
position. The attached patch adds one to both.

I think that's desirable. Will review the code soon.

+1.

--
Best Wishes,
Ashutosh Bapat

Thanks for checking!

Additionally the property does not exist message should also mention
the property graph name in case there are multiple property graph
references in the query. Can you please add that change.

done in v2.

--
Sami

On 24.08.26 12:43, Ashutosh Bapat wrote:

I was wrong. It's not specified in the syntax rules. Your change is
correct. In fact transformLabelExpr() does use
ERRCODE_UNDEFINED_OBJECT for missing labels. I also agree with your
reasoning behind not using ERRCODE_UNDEFINED_COLUMN.

ERRCODE_UNDEFINED_COLUMN is a subclass of syntax error, so I'm not sure
this analysis is really valid.

I was wrong. It's not specified in the syntax rules. Your change is
correct. In fact transformLabelExpr() does use
ERRCODE_UNDEFINED_OBJECT for missing labels. I also agree with your
reasoning behind not using ERRCODE_UNDEFINED_COLUMN.

ERRCODE_UNDEFINED_COLUMN is a subclass of syntax error, so I'm not sure
this analysis is really valid.

I only meant that the specific error code ERRCODE_SYNTAX_ERROR is wrong here.

The query has valid syntax, and the failure happens later when looking up the
property name in the property graph, so ERRCODE_UNDEFINED_OBJECT still looked
like the best fit, also for consistency with transformLabelExpr().

--
Sami

Hi Sami,

I tested v2 on master (07fdee7c8a8). It applies cleanly, make check passes
(243/243, graph_table included), and both lookups now report SQLSTATE 42704
with an error position.

1. The case that motivated adding the graph name -- more than one property
graph referenced in the query -- has no regression coverage; the error
tests all reference a single graph. 0001 attached (on top of v2) adds
one, reusing myshop and myshop2 (node_id exists in myshop but
nowhere in myshop2):

SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers) COLUMNS
(c.name AS n1)) g1, GRAPH_TABLE (myshop2 MATCH (o IS orders) COLUMNS
(o.node_id AS n2)) g2; -- error
-- ERROR: property "node_id" does not exist in property graph "myshop2"
-- LINE 1: ...GRAPH_TABLE (myshop2 MATCH (o IS orders) COLUMNS (o.node_id ...
-- ^

2. I also tried a label disjunction to see whether the caret finds the
label that actually failed to resolve -- v2 reports the right error:

SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS
customers|employees WHERE c.address = 'US')-[IS customer_orders]->(o
IS orders) COLUMNS (c.name AS customer_name));
-- ERROR: 42704: label "employees" does not exist in property graph "myshop"
-- LINE 1: ...me FROM GRAPH_TABLE (myshop MATCH (c IS customers|employees ...
-- ^

3. The rewrite-time lookups already use ERRCODE_UNDEFINED_OBJECT when a
property exists in the graph but does not resolve for the element
(replace_property_refs_mutator(), rewriteGraphTable.c:1145; likewise the
label-association error at :990):

SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers) COLUMNS
(c.ordered_when AS x));
-- ERROR: 42704: property "ordered_when" for element variable "c" not found

so with v2 the parse-time and rewrite-time classification agree.

4. One more ereport in parse_graphtable.c could take a position while at
it -- the quantifier check in transformGraphElementPattern(), where
gep->location is already available. 0002 attached adds it; the existing
test at graph_table.sql:94 then shows the position:

SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS
customers)->{1,2}(o IS orders) COLUMNS (c.name AS customer_name)); --
error
-- ERROR: element pattern quantifier is not supported
-- LINE 1: ...me FROM GRAPH_TABLE (myshop MATCH (c IS customers)->{1,2}(o ...
-- ^

Regards,
Rui Zhao