(SQL/PGQ) cache lookup failed for label
Hi all,
I noticed that the following SQL statement triggers the error message `cache lookup failed for label`.
```sql
CREATE TABLE vt (id text PRIMARY KEY, name text, age int);
CREATE TABLE et (id text PRIMARY KEY, src text REFERENCES vt(id), dst text REFERENCES vt(id));
INSERT INTO vt VALUES ('a', 'Alice', 30), ('b', 'Bob', 25);
INSERT INTO et VALUES ('e1', 'a', 'b');
CREATE PROPERTY GRAPH g
VERTEX TABLES (vt LABEL l1 PROPERTIES (name) LABEL l2 PROPERTIES (name, age))
EDGE TABLES (et SOURCE KEY (src) REFERENCES vt(id) DESTINATION KEY (dst) REFERENCES vt(id));
CREATE VIEW v1 AS SELECT * FROM GRAPH_TABLE(g MATCH (a IS l2)-[e IS et]->(b IS l2) COLUMNS (a.name, a.age, b.name AS bname));
ALTER PROPERTY GRAPH g ALTER VERTEX TABLE vt DROP LABEL l2;
SELECT * FROM v1;
```
Here are the actual test results; it appears to be caused by missing dependency information.
```sql
test=# CREATE TABLE vt (id text PRIMARY KEY, name text, age int);
CREATE TABLE
test=# CREATE TABLE et (id text PRIMARY KEY, src text REFERENCES vt(id), dst text REFERENCES vt(id));
CREATE TABLE
test=# INSERT INTO vt VALUES ('a', 'Alice', 30), ('b', 'Bob', 25);
INSERT 0 2
test=# INSERT INTO et VALUES ('e1', 'a', 'b');
INSERT 0 1
test=# CREATE PROPERTY GRAPH g
VERTEX TABLES (vt LABEL l1 PROPERTIES (name) LABEL l2 PROPERTIES (name, age))
EDGE TABLES (et SOURCE KEY (src) REFERENCES vt(id) DESTINATION KEY (dst) REFERENCES vt(id));
CREATE PROPERTY GRAPH
test=# CREATE VIEW v1 AS SELECT * FROM GRAPH_TABLE(g MATCH (a IS l2)-[e IS et]->(b IS l2) COLUMNS (a.name, a.age, b.name AS bname));
CREATE VIEW
test=# ALTER PROPERTY GRAPH g ALTER VERTEX TABLE vt DROP LABEL l2;
ALTER PROPERTY GRAPH
test=# SELECT * FROM v1;
2026-05-08 15:38:37.121 CST [175953] ERROR: cache lookup failed for label 16472
2026-05-08 15:38:37.121 CST [175953] STATEMENT: SELECT * FROM v1;
ERROR: cache lookup failed for label 16472
test=#
```
I've made some minor modifications; this is my diffs file. I'm not sure if anything is missing, so feel free to add to or supplement it.
```c
diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c
index fdb8e67e1f5..6a73b74fc9b 100644
--- a/src/backend/catalog/dependency.c
+++ b/src/backend/catalog/dependency.c
@@ -2247,6 +2247,22 @@ find_expr_references_walker(Node *node,
context->addrs);
/* fall through to examine substructure */
}
+ if (IsA(node, GraphLabelRef))
+ {
+ GraphLabelRef *lref = (GraphLabelRef *) node;
+
+ add_object_address(PropgraphLabelRelationId, lref->labelid, 0,
+ context->addrs);
+ return false;
+ }
+ if (IsA(node, GraphPropertyRef))
+ {
+ GraphPropertyRef *gpr = (GraphPropertyRef *) node;
+
+ add_object_address(PropgraphPropertyRelationId, gpr->propid, 0,
+ context->addrs);
+ return false;
+ }
else if (IsA(node, Query))
{
/* Recurse into RTE subquery or not-yet-planned sublink subquery */
@@ -2277,9 +2293,31 @@ find_expr_references_walker(Node *node,
switch (rte->rtekind)
{
case RTE_RELATION:
+ add_object_address(RelationRelationId, rte->relid, 0,
+ context->addrs);
+ break;
case RTE_GRAPH_TABLE:
add_object_address(RelationRelationId, rte->relid, 0,
context->addrs);
+
+ if (rte->graph_pattern)
+ {
+ GraphPattern *gp = rte->graph_pattern;
+ ListCell *lc1;
+
+ foreach(lc1, gp->path_pattern_list)
+ {
+ List *path_term = lfirst_node(List, lc1);
+ ListCell *lc2;
+
+ foreach(lc2, path_term)
+ {
+ GraphElementPattern *gep = lfirst_node(GraphElementPattern, lc2);
+
+ find_expr_references_walker(gep->labelexpr, context);
+ }
+ }
+ }
break;
case RTE_JOIN:```
Final running results
```sql
test=# CREATE TABLE vt (id text PRIMARY KEY, name text, age int);
CREATE TABLE et (id text PRIMARY KEY, src text REFERENCES vt(id), dst text REFERENCES vt(id));
INSERT INTO vt VALUES ('a', 'Alice', 30), ('b', 'Bob', 25);
INSERT INTO et VALUES ('e1', 'a', 'b');
CREATE PROPERTY GRAPH g
VERTEX TABLES (vt LABEL l1 PROPERTIES (name) LABEL l2 PROPERTIES (name, age))
EDGE TABLES (et SOURCE KEY (src) REFERENCES vt(id) DESTINATION KEY (dst) REFERENCES vt(id));
CREATE VIEW v1 AS SELECT * FROM GRAPH_TABLE(g MATCH (a IS l2)-[e IS et]->(b IS l2) COLUMNS (a.name, a.age, b.name AS bname));
ALTER PROPERTY GRAPH g ALTER VERTEX TABLE vt DROP LABEL l2;
SELECT * FROM v1;
CREATE TABLE
CREATE TABLE
INSERT 0 2
INSERT 0 1
CREATE PROPERTY GRAPH
CREATE VIEW
2026-05-08 16:24:59.938 CST [182833] ERROR: cannot drop label l2 of property graph g because other objects depend on it
2026-05-08 16:24:59.938 CST [182833] DETAIL: view v1 depends on label l2 of property graph g
2026-05-08 16:24:59.938 CST [182833] HINT: Use DROP ... CASCADE to drop the dependent objects too.
2026-05-08 16:24:59.938 CST [182833] STATEMENT: ALTER PROPERTY GRAPH g ALTER VERTEX TABLE vt DROP LABEL l2;
ERROR: cannot drop label l2 of property graph g because other objects depend on it
DETAIL: view v1 depends on label l2 of property graph g
HINT: Use DROP ... CASCADE to drop the dependent objects too.
name | age | bname
-------+-----+-------
Alice | 30 | Bob
(1 row)
```
--
regards,
Man Zeng
On Fri, May 8, 2026 at 2:10 PM zengman <zengman@halodbtech.com> wrote:
Hi all,
I noticed that the following SQL statement triggers the error message `cache lookup failed for label`.
```sql
CREATE TABLE vt (id text PRIMARY KEY, name text, age int);
CREATE TABLE et (id text PRIMARY KEY, src text REFERENCES vt(id), dst text REFERENCES vt(id));
INSERT INTO vt VALUES ('a', 'Alice', 30), ('b', 'Bob', 25);
INSERT INTO et VALUES ('e1', 'a', 'b');CREATE PROPERTY GRAPH g
VERTEX TABLES (vt LABEL l1 PROPERTIES (name) LABEL l2 PROPERTIES (name, age))
EDGE TABLES (et SOURCE KEY (src) REFERENCES vt(id) DESTINATION KEY (dst) REFERENCES vt(id));CREATE VIEW v1 AS SELECT * FROM GRAPH_TABLE(g MATCH (a IS l2)-[e IS et]->(b IS l2) COLUMNS (a.name, a.age, b.name AS bname));
ALTER PROPERTY GRAPH g ALTER VERTEX TABLE vt DROP LABEL l2;
SELECT * FROM v1;
```Here are the actual test results; it appears to be caused by missing dependency information.
```sql
test=# CREATE TABLE vt (id text PRIMARY KEY, name text, age int);
CREATE TABLE
test=# CREATE TABLE et (id text PRIMARY KEY, src text REFERENCES vt(id), dst text REFERENCES vt(id));
CREATE TABLE
test=# INSERT INTO vt VALUES ('a', 'Alice', 30), ('b', 'Bob', 25);
INSERT 0 2
test=# INSERT INTO et VALUES ('e1', 'a', 'b');
INSERT 0 1
test=# CREATE PROPERTY GRAPH g
VERTEX TABLES (vt LABEL l1 PROPERTIES (name) LABEL l2 PROPERTIES (name, age))
EDGE TABLES (et SOURCE KEY (src) REFERENCES vt(id) DESTINATION KEY (dst) REFERENCES vt(id));
CREATE PROPERTY GRAPH
test=# CREATE VIEW v1 AS SELECT * FROM GRAPH_TABLE(g MATCH (a IS l2)-[e IS et]->(b IS l2) COLUMNS (a.name, a.age, b.name AS bname));
CREATE VIEW
test=# ALTER PROPERTY GRAPH g ALTER VERTEX TABLE vt DROP LABEL l2;
ALTER PROPERTY GRAPH
test=# SELECT * FROM v1;
2026-05-08 15:38:37.121 CST [175953] ERROR: cache lookup failed for label 16472
2026-05-08 15:38:37.121 CST [175953] STATEMENT: SELECT * FROM v1;
ERROR: cache lookup failed for label 16472
test=#
```I've made some minor modifications; this is my diffs file. I'm not sure if anything is missing, so feel free to add to or supplement it.
Thanks for the report and the fix. Can you please create a patch/diff
file and attach it to the email please? It's easy to apply an
attachment than copying diff to a file and then applying it.
Please find some comments.
```c diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c index fdb8e67e1f5..6a73b74fc9b 100644 --- a/src/backend/catalog/dependency.c +++ b/src/backend/catalog/dependency.c @@ -2247,6 +2247,22 @@ find_expr_references_walker(Node *node, context->addrs); /* fall through to examine substructure */ } + if (IsA(node, GraphLabelRef)) + { + GraphLabelRef *lref = (GraphLabelRef *) node; + + add_object_address(PropgraphLabelRelationId, lref->labelid, 0, + context->addrs); + return false; + } + if (IsA(node, GraphPropertyRef)) + { + GraphPropertyRef *gpr = (GraphPropertyRef *) node; + + add_object_address(PropgraphPropertyRelationId, gpr->propid, 0, + context->addrs); + return false; + } else if (IsA(node, Query)) { /* Recurse into RTE subquery or not-yet-planned sublink subquery */ @@ -2277,9 +2293,31 @@ find_expr_references_walker(Node *node, switch (rte->rtekind) { case RTE_RELATION: + add_object_address(RelationRelationId, rte->relid, 0, + context->addrs); + break; case RTE_GRAPH_TABLE: add_object_address(RelationRelationId, rte->relid, 0, context->addrs); + + if (rte->graph_pattern) + { + GraphPattern *gp = rte->graph_pattern; + ListCell *lc1; + + foreach(lc1, gp->path_pattern_list) + { + List *path_term = lfirst_node(List, lc1); + ListCell *lc2; + + foreach(lc2, path_term) + { + GraphElementPattern *gep = lfirst_node(GraphElementPattern, lc2); + + find_expr_references_walker(gep->labelexpr, context); + } + } + }
You could use foreach_node() instead of foreach(). But I am wondering
whether we can directly call find_expr_references_walker() on
rte->graph_pattern. We need to walk rte->graph_table_columns as well.
break;
case RTE_JOIN:```
Final running results
```sql
test=# CREATE TABLE vt (id text PRIMARY KEY, name text, age int);
CREATE TABLE et (id text PRIMARY KEY, src text REFERENCES vt(id), dst text REFERENCES vt(id));
INSERT INTO vt VALUES ('a', 'Alice', 30), ('b', 'Bob', 25);
INSERT INTO et VALUES ('e1', 'a', 'b');CREATE PROPERTY GRAPH g
VERTEX TABLES (vt LABEL l1 PROPERTIES (name) LABEL l2 PROPERTIES (name, age))
EDGE TABLES (et SOURCE KEY (src) REFERENCES vt(id) DESTINATION KEY (dst) REFERENCES vt(id));CREATE VIEW v1 AS SELECT * FROM GRAPH_TABLE(g MATCH (a IS l2)-[e IS et]->(b IS l2) COLUMNS (a.name, a.age, b.name AS bname));
The patch needs a test. graph_table.sql already has some view
definitions, some of them using elements with multiple labels. Can you
please add a test using those views? For example after CREATE VIEW
customer_us, you could add a statement dropping label list_items from
all of the elements associated with that label. I guess
pg_get_viewdef() itself should throw an error with the fix, but you
could select from that view as well, if necessary. We also need a test
for drop property. Remember that the property is completely dropped
from a property graph only when it is dropped from all the labels
containing that property. Please apply patches from [1]/messages/by-id/CAExHW5tCCQhgDEfBTKWqe7bDqCUXhPpsqoGipL7Vpf0epcKkXA@mail.gmail.com -- Best Wishes, Ashutosh Bapat before adding
tests to your patch. With those patches added your test queries above
will throw a different error.
[1]: /messages/by-id/CAExHW5tCCQhgDEfBTKWqe7bDqCUXhPpsqoGipL7Vpf0epcKkXA@mail.gmail.com -- Best Wishes, Ashutosh Bapat
--
Best Wishes,
Ashutosh Bapat
The patch needs a test. graph_table.sql already has some view
definitions, some of them using elements with multiple labels. Can you
please add a test using those views? For example after CREATE VIEW
customer_us, you could add a statement dropping label list_items from
all of the elements associated with that label. I guess
pg_get_viewdef() itself should throw an error with the fix, but you
could select from that view as well, if necessary. We also need a test
for drop property. Remember that the property is completely dropped
from a property graph only when it is dropped from all the labels
containing that property. Please apply patches from [1] before adding
tests to your patch. With those patches added your test queries above
will throw a different error.[1] /messages/by-id/CAExHW5tCCQhgDEfBTKWqe7bDqCUXhPpsqoGipL7Vpf0epcKkXA@mail.gmail.com
Hi Ashutosh,
Thank you for the review and sorry for the late reply. I'm currently busy with company projects and may not have time to work on this right now.
If this is urgent, would you mind handling it? If it can wait, I'll come back and fix it when I have more availability.
--
regards,
Man Zeng
Hi,
On Thu, 14 May 2026 at 19:37, zengman <zengman@halodbtech.com> wrote:
The patch needs a test. graph_table.sql already has some view
definitions, some of them using elements with multiple labels. Can you
please add a test using those views? For example after CREATE VIEW
customer_us, you could add a statement dropping label list_items from
all of the elements associated with that label. I guess
pg_get_viewdef() itself should throw an error with the fix, but you
could select from that view as well, if necessary. We also need a test
for drop property. Remember that the property is completely dropped
from a property graph only when it is dropped from all the labels
containing that property. Please apply patches from [1] before adding
tests to your patch. With those patches added your test queries above
will throw a different error.[1]
/messages/by-id/CAExHW5tCCQhgDEfBTKWqe7bDqCUXhPpsqoGipL7Vpf0epcKkXA@mail.gmail.com
Hi Ashutosh,
Thank you for the review and sorry for the late reply. I'm currently busy
with company projects and may not have time to work on this right now.
If this is urgent, would you mind handling it? If it can wait, I'll come
back and fix it when I have more availability.
Thanks for the report.
I went through the thread and have attached a small patch for this.
The issue is that views/rules over GRAPH_TABLE store GraphLabelRef and
GraphPropertyRef nodes in the pg_rewrite parsetree, but dependency.c did
not record dependencies for those node types. So a view could depend on
label/property OIDs that were later removed by ALTER PROPERTY GRAPH, and
then fail at execution with "cache lookup failed for label".
The patch adds dependency walker cases for GraphLabelRef and
GraphPropertyRef. I didn't add any special traversal for RTE_GRAPH_TABLE.
query_tree_walker() already descends into rte->graph_pattern and
rte->graph_table_columns, so recognizing those two leaf nodes should be
enough?
I also added regression coverage for both cases:
DROP LABEL of a label used by a GRAPH_TABLE view
DROP PROPERTIES of a property used by a GRAPH_TABLE view
Both now fail with the normal dependency error until the view is dropped.
Thoughts?
Regards,
Ayush
Attachments:
v1-0001-SQL-PGQ-Record-dependencies-on-graph-labels-and-p.patchapplication/octet-stream; name=v1-0001-SQL-PGQ-Record-dependencies-on-graph-labels-and-p.patchDownload+72-1
Hi,
On Fri, 15 May 2026 at 16:07, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
wrote:
Hi,
On Thu, 14 May 2026 at 19:37, zengman <zengman@halodbtech.com> wrote:
The patch needs a test. graph_table.sql already has some view
definitions, some of them using elements with multiple labels. Can you
please add a test using those views? For example after CREATE VIEW
customer_us, you could add a statement dropping label list_items from
all of the elements associated with that label. I guess
pg_get_viewdef() itself should throw an error with the fix, but you
could select from that view as well, if necessary. We also need a test
for drop property. Remember that the property is completely dropped
from a property graph only when it is dropped from all the labels
containing that property. Please apply patches from [1] before adding
tests to your patch. With those patches added your test queries above
will throw a different error.[1]
/messages/by-id/CAExHW5tCCQhgDEfBTKWqe7bDqCUXhPpsqoGipL7Vpf0epcKkXA@mail.gmail.com
Hi Ashutosh,
Thank you for the review and sorry for the late reply. I'm currently busy
with company projects and may not have time to work on this right now.
If this is urgent, would you mind handling it? If it can wait, I'll come
back and fix it when I have more availability.Thanks for the report.
I went through the thread and have attached a small patch for this.
The issue is that views/rules over GRAPH_TABLE store GraphLabelRef and
GraphPropertyRef nodes in the pg_rewrite parsetree, but dependency.c did
not record dependencies for those node types. So a view could depend on
label/property OIDs that were later removed by ALTER PROPERTY GRAPH, and
then fail at execution with "cache lookup failed for label".The patch adds dependency walker cases for GraphLabelRef and
GraphPropertyRef. I didn't add any special traversal for RTE_GRAPH_TABLE.
query_tree_walker() already descends into rte->graph_pattern and
rte->graph_table_columns, so recognizing those two leaf nodes should be
enough?I also added regression coverage for both cases:
DROP LABEL of a label used by a GRAPH_TABLE view
DROP PROPERTIES of a property used by a GRAPH_TABLE viewBoth now fail with the normal dependency error until the view is dropped.
Thoughts?
Attaching v2 that uses existing views for test cases.
Regards,
Ayush
Attachments:
v2-0001-SQL-PGQ-Record-dependencies-on-graph-labels-and-p.patchapplication/octet-stream; name=v2-0001-SQL-PGQ-Record-dependencies-on-graph-labels-and-p.patchDownload+44-1
Hi Ayush,
On Fri, May 15, 2026 at 6:55 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:
Hi,
On Fri, 15 May 2026 at 16:07, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
Hi,
On Thu, 14 May 2026 at 19:37, zengman <zengman@halodbtech.com> wrote:
The patch needs a test. graph_table.sql already has some view
definitions, some of them using elements with multiple labels. Can you
please add a test using those views? For example after CREATE VIEW
customer_us, you could add a statement dropping label list_items from
all of the elements associated with that label. I guess
pg_get_viewdef() itself should throw an error with the fix, but you
could select from that view as well, if necessary. We also need a test
for drop property. Remember that the property is completely dropped
from a property graph only when it is dropped from all the labels
containing that property. Please apply patches from [1] before adding
tests to your patch. With those patches added your test queries above
will throw a different error.[1] /messages/by-id/CAExHW5tCCQhgDEfBTKWqe7bDqCUXhPpsqoGipL7Vpf0epcKkXA@mail.gmail.com
Hi Ashutosh,
Thank you for the review and sorry for the late reply. I'm currently busy with company projects and may not have time to work on this right now.
If this is urgent, would you mind handling it? If it can wait, I'll come back and fix it when I have more availability.Thanks for the report.
I went through the thread and have attached a small patch for this.
The issue is that views/rules over GRAPH_TABLE store GraphLabelRef and
GraphPropertyRef nodes in the pg_rewrite parsetree, but dependency.c did
not record dependencies for those node types. So a view could depend on
label/property OIDs that were later removed by ALTER PROPERTY GRAPH, and
then fail at execution with "cache lookup failed for label".The patch adds dependency walker cases for GraphLabelRef and
GraphPropertyRef. I didn't add any special traversal for RTE_GRAPH_TABLE.
query_tree_walker() already descends into rte->graph_pattern and
rte->graph_table_columns, so recognizing those two leaf nodes should be
enough?
WFM.
I also added regression coverage for both cases:
DROP LABEL of a label used by a GRAPH_TABLE view
DROP PROPERTIES of a property used by a GRAPH_TABLE viewBoth now fail with the normal dependency error until the view is dropped.
Thoughts?
I'd suggest adding two stmts to the regression that can cover that walk of
graph_table_columns is also working.
[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE customers ALTER LABEL customers DROP PROPERTIES
(name);
ALTER PROPERTY GRAPH
Time: 1.312 ms
[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE products ALTER LABEL products DROP PROPERTIES
(name);
ERROR: cannot drop property name of property graph myshop because
other objects depend on it
DETAIL: view customers_us depends on property name of property graph myshop
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Time: 2.231 ms
Attaching v2 that uses existing views for test cases.
Regards,
Ayush
--
Regards
Junwang Zhao
Hi,
On Fri, 15 May 2026 at 20:31, Junwang Zhao <zhjwpku@gmail.com> wrote:
Hi Ayush,
I also added regression coverage for both cases:
DROP LABEL of a label used by a GRAPH_TABLE view
DROP PROPERTIES of a property used by a GRAPH_TABLE viewBoth now fail with the normal dependency error until the view is
dropped.
Thoughts?
I'd suggest adding two stmts to the regression that can cover that walk of
graph_table_columns is also working.[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE customers ALTER LABEL customers DROP PROPERTIES
(name);
ALTER PROPERTY GRAPH
Time: 1.312 ms[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE products ALTER LABEL products DROP PROPERTIES
(name);
ERROR: cannot drop property name of property graph myshop because
other objects depend on it
DETAIL: view customers_us depends on property name of property graph
myshop
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Time: 2.231 ms
Good point, thanks. I added that coverage in the attached v3.
The test now also drops customers.name first, which is allowed because the
graph-level property still exists via products.name, and then verifies that
dropping products.name is rejected with the dependency error from
customers_us. That should cover GraphPropertyRef nodes reached through the
GRAPH_TABLE COLUMNS list, in addition to the existing label and
graph-pattern
property cases.
I re-added customers.name afterward so the existing myshop graph remains
unchanged for the following tests.
Regards,
Ayush
Attachments:
v3-0001-SQL-PGQ-Record-dependencies-on-graph-labels-and-p.patchapplication/octet-stream; name=v3-0001-SQL-PGQ-Record-dependencies-on-graph-labels-and-p.patchDownload+59-1
On Fri, May 15, 2026 at 8:43 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:
Hi,
On Fri, 15 May 2026 at 20:31, Junwang Zhao <zhjwpku@gmail.com> wrote:
Hi Ayush,
I also added regression coverage for both cases:
DROP LABEL of a label used by a GRAPH_TABLE view
DROP PROPERTIES of a property used by a GRAPH_TABLE viewBoth now fail with the normal dependency error until the view is dropped.
Thoughts?
I'd suggest adding two stmts to the regression that can cover that walk of
graph_table_columns is also working.[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE customers ALTER LABEL customers DROP PROPERTIES
(name);
ALTER PROPERTY GRAPH
Time: 1.312 ms[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE products ALTER LABEL products DROP PROPERTIES
(name);
ERROR: cannot drop property name of property graph myshop because
other objects depend on it
DETAIL: view customers_us depends on property name of property graph myshop
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Time: 2.231 msGood point, thanks. I added that coverage in the attached v3.
The test now also drops customers.name first, which is allowed because the
graph-level property still exists via products.name, and then verifies that
dropping products.name is rejected with the dependency error from
customers_us. That should cover GraphPropertyRef nodes reached through the
GRAPH_TABLE COLUMNS list, in addition to the existing label and graph-pattern
property cases.I re-added customers.name afterward so the existing myshop graph remains
unchanged for the following tests.
Thanks Ayush for working on this and providing the patch. Thanks
Junwang for reviewing it.
I have some more comments.
}
+ else if (IsA(node, GraphLabelRef))
+ {
+ GraphLabelRef *glr = (GraphLabelRef *) node;
+
+ /*
+ * GRAPH_TABLE label reference: depend on the label catalog entry.
+ * No expression substructure to recurse into.That comment is correct, however, the case doesn't return false,
giving an impression that we are recursing into the substructure.
expression_tree_walker() then returns false. But I am seeing an
inconsistency in when to "return false" and when not to. For example,
for some primitive nodes in expression_tree_walker() like Var, this
function returns false. But for other primitive nodes like Param it
doesn't. And there's not comment explaining this difference. I guess
newer additions to this function are relying on expression_tree_walker
to return false. So I just removed the misleading comment and let the
two new nodes rely on expression_tree_walker().
+ */
+ add_object_address(PropgraphLabelRelationId, glr->labelid, 0,
+ context->addrs);
+ }
+ else if (IsA(node, GraphPropertyRef))
+ {
+ GraphPropertyRef *gpr = (GraphPropertyRef *) node;
+
+ /* GRAPH_TABLE property reference: depend on the property entry. */
+ add_object_address(PropgraphPropertyRelationId, gpr->propid, 0,
+ context->addrs);
+ }@@ -536,6 +536,22 @@ SELECT g.* FROM x1,
ORDER BY customer_name, product_name;
SELECT pg_get_viewdef('customers_us'::regclass);
+-- A view defined over GRAPH_TABLE should record dependencies on the labels
+-- and properties it references, so they cannot be dropped from under it.
+ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE order_items DROP LABEL list_items;
+ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE wishlist_items
+ DROP LABEL list_items; -- error
+ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE order_items
+ ADD LABEL list_items PROPERTIES (order_id AS link_id, product_no);
+ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers
+ ALTER LABEL customers DROP PROPERTIES (address); -- error
+ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers
+ ALTER LABEL customers DROP PROPERTIES (name);
+ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE products
+ ALTER LABEL products DROP PROPERTIES (name); -- error
+ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers
+ ALTER LABEL customers ADD PROPERTIES (name);
+Without the code changes, we do not see "cache lookup failed for label
" error, because there is nothing that uses this view after the drop.
In the attached patch, I have moved the DDL statements before
pg_get_viewdef() which throws "cache lookup failed" error without code
changes and for every DDL statement when we try it separately.
My earlier comment or the test by Man might have misled you into
thinking that we need to drop properties or labels which are defined
multiple times so that we test that the dependency error does not
trigger when a property or a label is not orphaned. Sorry if that's
the case. I don't think that's the goal here. Further, such tests
require additional DDL to restore property graph state and also change
the view definition produced by pg_get_viewdef(). So I used DDLs that
drop properties or labels which are defined only once.
I shortened the commit message by taking essential elements from your
commit message.
Please review the attached patch.
--
Best Wishes,
Ashutosh Bapat
Attachments:
v20260517-0001-Prevent-dropping-the-last-label-from-a-pro.patchtext/x-patch; charset=US-ASCII; name=v20260517-0001-Prevent-dropping-the-last-label-from-a-pro.patchDownload+119-7
Regards
Junwang Zhao
On Mon, May 18, 2026 at 07:29 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
wrote:
On Fri, May 15, 2026 at 8:43 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:Hi,
On Fri, 15 May 2026 at 20:31, Junwang Zhao <zhjwpku@gmail.com> wrote:
Hi Ayush,
I also added regression coverage for both cases:
DROP LABEL of a label used by a GRAPH_TABLE view
DROP PROPERTIES of a property used by a GRAPH_TABLE viewBoth now fail with the normal dependency error until the view is
dropped.
Thoughts?
I'd suggest adding two stmts to the regression that can cover that walk
of
graph_table_columns is also working.
[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE customers ALTER LABEL customers DROP PROPERTIES
(name);
ALTER PROPERTY GRAPH
Time: 1.312 ms[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE products ALTER LABEL products DROP PROPERTIES
(name);
ERROR: cannot drop property name of property graph myshop because
other objects depend on it
DETAIL: view customers_us depends on property name of property graphmyshop
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Time: 2.231 msGood point, thanks. I added that coverage in the attached v3.
The test now also drops customers.name first, which is allowed because
the
graph-level property still exists via products.name, and then verifies
that
dropping products.name is rejected with the dependency error from
customers_us. That should cover GraphPropertyRef nodes reached throughthe
GRAPH_TABLE COLUMNS list, in addition to the existing label and
graph-pattern
property cases.
I re-added customers.name afterward so the existing myshop graph remains
unchanged for the following tests.Thanks Ayush for working on this and providing the patch. Thanks
Junwang for reviewing it.I have some more comments.
} + else if (IsA(node, GraphLabelRef)) + { + GraphLabelRef *glr = (GraphLabelRef *) node; + + /* + * GRAPH_TABLE label reference: depend on the label catalog entry. + * No expression substructure to recurse into.That comment is correct, however, the case doesn't return false,
giving an impression that we are recursing into the substructure.
expression_tree_walker() then returns false. But I am seeing an
inconsistency in when to "return false" and when not to. For example,
for some primitive nodes in expression_tree_walker() like Var, this
function returns false. But for other primitive nodes like Param it
doesn't. And there's not comment explaining this difference. I guess
newer additions to this function are relying on expression_tree_walker
to return false. So I just removed the misleading comment and let the
two new nodes rely on expression_tree_walker().+ */ + add_object_address(PropgraphLabelRelationId, glr->labelid, 0, + context->addrs); + } + else if (IsA(node, GraphPropertyRef)) + { + GraphPropertyRef *gpr = (GraphPropertyRef *) node; + + /* GRAPH_TABLE property reference: depend on the property entry. */ + add_object_address(PropgraphPropertyRelationId, gpr->propid, 0, + context->addrs); + }@@ -536,6 +536,22 @@ SELECT g.* FROM x1, ORDER BY customer_name, product_name; SELECT pg_get_viewdef('customers_us'::regclass); +-- A view defined over GRAPH_TABLE should record dependencies on the labels +-- and properties it references, so they cannot be dropped from under it. +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE order_items DROP LABEL list_items; +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE wishlist_items + DROP LABEL list_items; -- error +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE order_items + ADD LABEL list_items PROPERTIES (order_id AS link_id, product_no); +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers DROP PROPERTIES (address); -- error +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers DROP PROPERTIES (name); +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE products + ALTER LABEL products DROP PROPERTIES (name); -- error +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers ADD PROPERTIES (name); +Without the code changes, we do not see "cache lookup failed for label
" error, because there is nothing that uses this view after the drop.
In the attached patch, I have moved the DDL statements before
pg_get_viewdef() which throws "cache lookup failed" error without code
changes and for every DDL statement when we try it separately.My earlier comment or the test by Man might have misled you into
thinking that we need to drop properties or labels which are defined
multiple times so that we test that the dependency error does not
trigger when a property or a label is not orphaned. Sorry if that's
the case. I don't think that's the goal here. Further, such tests
require additional DDL to restore property graph state and also change
the view definition produced by pg_get_viewdef(). So I used DDLs that
drop properties or labels which are defined only once.I shortened the commit message by taking essential elements from your
commit message.Please review the attached patch.
The attached patch seems not for this thread.
Show quoted text
--
Best Wishes,
Ashutosh Bapat
On Sun, May 17, 2026 at 5:12 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
Regards
Junwang ZhaoOn Mon, May 18, 2026 at 07:29 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
On Fri, May 15, 2026 at 8:43 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:Hi,
On Fri, 15 May 2026 at 20:31, Junwang Zhao <zhjwpku@gmail.com> wrote:
Hi Ayush,
I also added regression coverage for both cases:
DROP LABEL of a label used by a GRAPH_TABLE view
DROP PROPERTIES of a property used by a GRAPH_TABLE viewBoth now fail with the normal dependency error until the view is dropped.
Thoughts?
I'd suggest adding two stmts to the regression that can cover that walk of
graph_table_columns is also working.[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE customers ALTER LABEL customers DROP PROPERTIES
(name);
ALTER PROPERTY GRAPH
Time: 1.312 ms[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE products ALTER LABEL products DROP PROPERTIES
(name);
ERROR: cannot drop property name of property graph myshop because
other objects depend on it
DETAIL: view customers_us depends on property name of property graph myshop
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Time: 2.231 msGood point, thanks. I added that coverage in the attached v3.
The test now also drops customers.name first, which is allowed because the
graph-level property still exists via products.name, and then verifies that
dropping products.name is rejected with the dependency error from
customers_us. That should cover GraphPropertyRef nodes reached through the
GRAPH_TABLE COLUMNS list, in addition to the existing label and graph-pattern
property cases.I re-added customers.name afterward so the existing myshop graph remains
unchanged for the following tests.Thanks Ayush for working on this and providing the patch. Thanks
Junwang for reviewing it.I have some more comments.
} + else if (IsA(node, GraphLabelRef)) + { + GraphLabelRef *glr = (GraphLabelRef *) node; + + /* + * GRAPH_TABLE label reference: depend on the label catalog entry. + * No expression substructure to recurse into.That comment is correct, however, the case doesn't return false,
giving an impression that we are recursing into the substructure.
expression_tree_walker() then returns false. But I am seeing an
inconsistency in when to "return false" and when not to. For example,
for some primitive nodes in expression_tree_walker() like Var, this
function returns false. But for other primitive nodes like Param it
doesn't. And there's not comment explaining this difference. I guess
newer additions to this function are relying on expression_tree_walker
to return false. So I just removed the misleading comment and let the
two new nodes rely on expression_tree_walker().+ */ + add_object_address(PropgraphLabelRelationId, glr->labelid, 0, + context->addrs); + } + else if (IsA(node, GraphPropertyRef)) + { + GraphPropertyRef *gpr = (GraphPropertyRef *) node; + + /* GRAPH_TABLE property reference: depend on the property entry. */ + add_object_address(PropgraphPropertyRelationId, gpr->propid, 0, + context->addrs); + }@@ -536,6 +536,22 @@ SELECT g.* FROM x1, ORDER BY customer_name, product_name; SELECT pg_get_viewdef('customers_us'::regclass); +-- A view defined over GRAPH_TABLE should record dependencies on the labels +-- and properties it references, so they cannot be dropped from under it. +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE order_items DROP LABEL list_items; +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE wishlist_items + DROP LABEL list_items; -- error +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE order_items + ADD LABEL list_items PROPERTIES (order_id AS link_id, product_no); +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers DROP PROPERTIES (address); -- error +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers DROP PROPERTIES (name); +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE products + ALTER LABEL products DROP PROPERTIES (name); -- error +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers ADD PROPERTIES (name); +Without the code changes, we do not see "cache lookup failed for label
" error, because there is nothing that uses this view after the drop.
In the attached patch, I have moved the DDL statements before
pg_get_viewdef() which throws "cache lookup failed" error without code
changes and for every DDL statement when we try it separately.My earlier comment or the test by Man might have misled you into
thinking that we need to drop properties or labels which are defined
multiple times so that we test that the dependency error does not
trigger when a property or a label is not orphaned. Sorry if that's
the case. I don't think that's the goal here. Further, such tests
require additional DDL to restore property graph state and also change
the view definition produced by pg_get_viewdef(). So I used DDLs that
drop properties or labels which are defined only once.I shortened the commit message by taking essential elements from your
commit message.Please review the attached patch.
The attached patch seems not for this thread.
Thanks for noticing. Here's attached correct patch.
--
Best Wishes,
Ashutosh Bapat
Attachments:
v20260517-0001-Record-dependencies-on-graph-labels-and-pr.patchtext/x-patch; charset=US-ASCII; name=v20260517-0001-Record-dependencies-on-graph-labels-and-pr.patchDownload+59-9
On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
On Sun, May 17, 2026 at 5:12 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
Regards
Junwang ZhaoOn Mon, May 18, 2026 at 07:29 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
On Fri, May 15, 2026 at 8:43 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:Hi,
On Fri, 15 May 2026 at 20:31, Junwang Zhao <zhjwpku@gmail.com> wrote:
Hi Ayush,
I also added regression coverage for both cases:
DROP LABEL of a label used by a GRAPH_TABLE view
DROP PROPERTIES of a property used by a GRAPH_TABLE viewBoth now fail with the normal dependency error until the view is dropped.
Thoughts?
I'd suggest adding two stmts to the regression that can cover that walk of
graph_table_columns is also working.[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE customers ALTER LABEL customers DROP PROPERTIES
(name);
ALTER PROPERTY GRAPH
Time: 1.312 ms[local] zhjwpku@postgres:5432-52789=# ALTER PROPERTY GRAPH myshop
ALTER VERTEX TABLE products ALTER LABEL products DROP PROPERTIES
(name);
ERROR: cannot drop property name of property graph myshop because
other objects depend on it
DETAIL: view customers_us depends on property name of property graph myshop
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Time: 2.231 msGood point, thanks. I added that coverage in the attached v3.
The test now also drops customers.name first, which is allowed because the
graph-level property still exists via products.name, and then verifies that
dropping products.name is rejected with the dependency error from
customers_us. That should cover GraphPropertyRef nodes reached through the
GRAPH_TABLE COLUMNS list, in addition to the existing label and graph-pattern
property cases.I re-added customers.name afterward so the existing myshop graph remains
unchanged for the following tests.Thanks Ayush for working on this and providing the patch. Thanks
Junwang for reviewing it.I have some more comments.
} + else if (IsA(node, GraphLabelRef)) + { + GraphLabelRef *glr = (GraphLabelRef *) node; + + /* + * GRAPH_TABLE label reference: depend on the label catalog entry. + * No expression substructure to recurse into.That comment is correct, however, the case doesn't return false,
giving an impression that we are recursing into the substructure.
expression_tree_walker() then returns false. But I am seeing an
inconsistency in when to "return false" and when not to. For example,
for some primitive nodes in expression_tree_walker() like Var, this
function returns false. But for other primitive nodes like Param it
doesn't. And there's not comment explaining this difference. I guess
newer additions to this function are relying on expression_tree_walker
to return false. So I just removed the misleading comment and let the
two new nodes rely on expression_tree_walker().+ */ + add_object_address(PropgraphLabelRelationId, glr->labelid, 0, + context->addrs); + } + else if (IsA(node, GraphPropertyRef)) + { + GraphPropertyRef *gpr = (GraphPropertyRef *) node; + + /* GRAPH_TABLE property reference: depend on the property entry. */ + add_object_address(PropgraphPropertyRelationId, gpr->propid, 0, + context->addrs); + }@@ -536,6 +536,22 @@ SELECT g.* FROM x1, ORDER BY customer_name, product_name; SELECT pg_get_viewdef('customers_us'::regclass); +-- A view defined over GRAPH_TABLE should record dependencies on the labels +-- and properties it references, so they cannot be dropped from under it. +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE order_items DROP LABEL list_items; +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE wishlist_items + DROP LABEL list_items; -- error +ALTER PROPERTY GRAPH myshop ALTER EDGE TABLE order_items + ADD LABEL list_items PROPERTIES (order_id AS link_id, product_no); +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers DROP PROPERTIES (address); -- error +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers DROP PROPERTIES (name); +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE products + ALTER LABEL products DROP PROPERTIES (name); -- error +ALTER PROPERTY GRAPH myshop ALTER VERTEX TABLE customers + ALTER LABEL customers ADD PROPERTIES (name); +Without the code changes, we do not see "cache lookup failed for label
" error, because there is nothing that uses this view after the drop.
In the attached patch, I have moved the DDL statements before
pg_get_viewdef() which throws "cache lookup failed" error without code
changes and for every DDL statement when we try it separately.My earlier comment or the test by Man might have misled you into
thinking that we need to drop properties or labels which are defined
multiple times so that we test that the dependency error does not
trigger when a property or a label is not orphaned. Sorry if that's
the case. I don't think that's the goal here. Further, such tests
require additional DDL to restore property graph state and also change
the view definition produced by pg_get_viewdef(). So I used DDLs that
drop properties or labels which are defined only once.
+1 for this change, we don't need to re-add the label and property to myshop.
I shortened the commit message by taking essential elements from your
commit message.Please review the attached patch.
The attached patch seems not for this thread.
Thanks for noticing. Here's attached correct patch.
The patch LGTM, thanks for taking care of this.
--
Best Wishes,
Ashutosh Bapat
--
Regards
Junwang Zhao
Hi,
On Mon, 18 May 2026 at 07:37, Junwang Zhao <zhjwpku@gmail.com> wrote:
On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:I shortened the commit message by taking essential elements from your
commit message.Please review the attached patch.
The attached patch seems not for this thread.
Thanks for noticing. Here's attached correct patch.
The patch LGTM, thanks for taking care of this.
+1, LGTM
I've changed the status in CF entry status to Ready for Committer.
https://commitfest.postgresql.org/patch/6760/
Regards,
Ayush
On Sun, May 17, 2026 at 11:26 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:
Hi,
On Mon, 18 May 2026 at 07:37, Junwang Zhao <zhjwpku@gmail.com> wrote:
On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:I shortened the commit message by taking essential elements from your
commit message.Please review the attached patch.
The attached patch seems not for this thread.
Thanks for noticing. Here's attached correct patch.
The patch LGTM, thanks for taking care of this.
+1, LGTM
I've changed the status in CF entry status to Ready for Committer.
https://commitfest.postgresql.org/patch/6760/
Thanks Ayush.
While working on this, I found two other problems. Before we dive into
those, I think we should commit the current patch. It need not wait
for a solution to these problems.
I was checking whether we should be expanding an empty label during
the transformation stage instead of rewrite phase so that, in case the
graph pattern is part of a view definition, the set of labels the
empty label expression resolves to is stored in the catalogs. That
way, we can create a dependency of view on the set of labels at the
time of view. After discussing it with Peter Eisentraut, we feel that
doing so will be good for future-proofing pg_dump of views containing
graph patterns with empty labels. We will definitely need it before
supporting all properties reference since the properties that the all
properties reference expands to depends upon the set of labels in the
label expression. We need to create dependencies between those
properties and the view and hence need dependencies between labels
(that the empty label expression resolves to) and the view. I will
provide a patch for the same soon.
When trying different things which could lead to invalidation of view
if we don't add the dependency between labels (that the empty label
expression resolves to) and the view, I found another way to
invalidate the view.
To reproduce it, run the following statements after running
graph_table.sql tests.
CREATE VIEW v_empty_label AS SELECT * FROM GRAPH_TABLE (g1 MATCH (v
WHERE v.vprop1 = 10) COLUMNS (v.elname));
BEGIN;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v1 DROP LABEL l1;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v2 DROP LABEL l1;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v3 DROP LABEL l1;
SELECT * FROM v_empty_label;
ROLLBACK;
The three ALTER TABLE statements leave the label behind since it's
associated with the edge tables. The SELECT statement still throws
"ERROR: property "elname" for element variable "v" not found". If we
expand the empty label reference in the transformation phase and
record dependencies between those labels and the view, we get a
different error "ERROR: no property graph element of type "vertex"
has label "l1" associated with it in property graph "g1"". The first
error is a bit obscure compared to the second one. So there's relative
improvement. Myself and Peter thought that the second error is an
artifact of the term "vertex labels" in the standard; a term which is
not properly defined in the standard. There are two solutions
1. We create vertex label and edge label as separate objects and
record depdencies accordingly
2. We ignore the term "vertex/edge label" in the standard and handle
labels that exist in property graphs but have no associated element of
required type in the query. I think this will require some corrections
in standard to standardize the outcome of such queries.
I will provide patches once we decide which approach to take.
--
Best Wishes,
Ashutosh Bapat
On Fri, May 22, 2026 at 12:07 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
On Sun, May 17, 2026 at 11:26 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:Hi,
On Mon, 18 May 2026 at 07:37, Junwang Zhao <zhjwpku@gmail.com> wrote:
On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:I shortened the commit message by taking essential elements from your
commit message.Please review the attached patch.
The attached patch seems not for this thread.
Thanks for noticing. Here's attached correct patch.
The patch LGTM, thanks for taking care of this.
+1, LGTM
I've changed the status in CF entry status to Ready for Committer.
https://commitfest.postgresql.org/patch/6760/Thanks Ayush.
While working on this, I found two other problems. Before we dive into
those, I think we should commit the current patch. It need not wait
for a solution to these problems.I was checking whether we should be expanding an empty label during
the transformation stage instead of rewrite phase so that, in case the
graph pattern is part of a view definition, the set of labels the
empty label expression resolves to is stored in the catalogs. That
way, we can create a dependency of view on the set of labels at the
time of view. After discussing it with Peter Eisentraut, we feel that
doing so will be good for future-proofing pg_dump of views containing
graph patterns with empty labels. We will definitely need it before
supporting all properties reference since the properties that the all
properties reference expands to depends upon the set of labels in the
label expression. We need to create dependencies between those
properties and the view and hence need dependencies between labels
(that the empty label expression resolves to) and the view. I will
provide a patch for the same soon.
While working on this I found another issue. An empty label expression
may turn into no label which does not have any syntax level support.
Hence we can't dump a view containing such an empty label expression.
For now I have prohibited empty label expressions which do not resolve
to any label as an unsupported feature. I doubt if there will be any
valid use case for such a label expression.
As a result a test which tests dependency between a view and the
property graph in create_property_graph.sql failed. Failure is
accidental as test uses an empty property graph for this purpose. I
fixed it by adding a vertex table to the property graph being
referenced in the view.
The commit message just mentions the label dependency asymmetry
between explicitly mentioned labels and labels resulting from empty
label expression. I haven't gone into the details of
all-properties-reference to keep it simple. The discussion link should
lead a curious reader to the complex discussion here.
I did reconsider whether to fix this right now or whether we can
postpone it till we support all-properties reference. If we don't fix
this, a query containing empty label expression will return different
result as the set of labels in the property graph changes. When we
will support all properties reference, we will have to fix this and
then the behaviour will change breaking backward compatibility. So I
think we have to fix this now.
When trying different things which could lead to invalidation of view
if we don't add the dependency between labels (that the empty label
expression resolves to) and the view, I found another way to
invalidate the view.To reproduce it, run the following statements after running
graph_table.sql tests.
CREATE VIEW v_empty_label AS SELECT * FROM GRAPH_TABLE (g1 MATCH (v
WHERE v.vprop1 = 10) COLUMNS (v.elname));
BEGIN;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v1 DROP LABEL l1;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v2 DROP LABEL l1;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v3 DROP LABEL l1;
SELECT * FROM v_empty_label;
ROLLBACK;The three ALTER TABLE statements leave the label behind since it's
associated with the edge tables. The SELECT statement still throws
"ERROR: property "elname" for element variable "v" not found". If we
expand the empty label reference in the transformation phase and
record dependencies between those labels and the view, we get a
different error "ERROR: no property graph element of type "vertex"
has label "l1" associated with it in property graph "g1"". The first
error is a bit obscure compared to the second one. So there's relative
improvement. Myself and Peter thought that the second error is an
artifact of the term "vertex labels" in the standard; a term which is
not properly defined in the standard. There are two solutions1. We create vertex label and edge label as separate objects and
record depdencies accordingly
2. We ignore the term "vertex/edge label" in the standard and handle
labels that exist in property graphs but have no associated element of
required type in the query. I think this will require some corrections
in standard to standardize the outcome of such queries.I will provide patches once we decide which approach to take.
For now I have added a test case exhibiting this behaviour. If we
commit the test, somebody who comes across this behaviour will know
why the current behaviour is the way it is and what's the way forward.
But if we don't commit it, which is ok, they will consider this as
buggy behaviour and report it. I am fine either way.
As I mentioned earlier, I am creating patches for all outstanding
issues from the same branch. So the patches attached here do not start
from 0001, but they apply with git am on the latest master for me
without any problem.
0005 - fixes `cache lookup failed for label`
0006 - fixes empty label expression and view behaviour
0007 - issue with labels shared by vertex and edges
--
Best Wishes,
Ashutosh Bapat
Attachments:
v20260601-0007-View-referencing-labels-shared-by-vertex-a.patchtext/x-patch; charset=US-ASCII; name=v20260601-0007-View-referencing-labels-shared-by-vertex-a.patchDownload+33-1
v20260601-0005-Record-dependencies-on-graph-labels-and-pr.patchtext/x-patch; charset=US-ASCII; name=v20260601-0005-Record-dependencies-on-graph-labels-and-pr.patchDownload+59-9
v20260601-0006-Empty-label-expression-in-view-definition.patchtext/x-patch; charset=US-ASCII; name=v20260601-0006-Empty-label-expression-in-view-definition.patchDownload+178-64
On Thu, Jun 4, 2026 at 6:45 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
On Fri, May 22, 2026 at 12:07 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:On Sun, May 17, 2026 at 11:26 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:Hi,
On Mon, 18 May 2026 at 07:37, Junwang Zhao <zhjwpku@gmail.com> wrote:
On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:I shortened the commit message by taking essential elements from your
commit message.Please review the attached patch.
The attached patch seems not for this thread.
Thanks for noticing. Here's attached correct patch.
The patch LGTM, thanks for taking care of this.
+1, LGTM
I've changed the status in CF entry status to Ready for Committer.
https://commitfest.postgresql.org/patch/6760/Thanks Ayush.
While working on this, I found two other problems. Before we dive into
those, I think we should commit the current patch. It need not wait
for a solution to these problems.I was checking whether we should be expanding an empty label during
the transformation stage instead of rewrite phase so that, in case the
graph pattern is part of a view definition, the set of labels the
empty label expression resolves to is stored in the catalogs. That
way, we can create a dependency of view on the set of labels at the
time of view. After discussing it with Peter Eisentraut, we feel that
doing so will be good for future-proofing pg_dump of views containing
graph patterns with empty labels. We will definitely need it before
supporting all properties reference since the properties that the all
properties reference expands to depends upon the set of labels in the
label expression. We need to create dependencies between those
properties and the view and hence need dependencies between labels
(that the empty label expression resolves to) and the view. I will
provide a patch for the same soon.While working on this I found another issue. An empty label expression
may turn into no label which does not have any syntax level support.
Hence we can't dump a view containing such an empty label expression.
For now I have prohibited empty label expressions which do not resolve
to any label as an unsupported feature. I doubt if there will be any
valid use case for such a label expression.As a result a test which tests dependency between a view and the
property graph in create_property_graph.sql failed. Failure is
accidental as test uses an empty property graph for this purpose. I
fixed it by adding a vertex table to the property graph being
referenced in the view.The commit message just mentions the label dependency asymmetry
between explicitly mentioned labels and labels resulting from empty
label expression. I haven't gone into the details of
all-properties-reference to keep it simple. The discussion link should
lead a curious reader to the complex discussion here.I did reconsider whether to fix this right now or whether we can
postpone it till we support all-properties reference. If we don't fix
this, a query containing empty label expression will return different
result as the set of labels in the property graph changes. When we
will support all properties reference, we will have to fix this and
then the behaviour will change breaking backward compatibility. So I
think we have to fix this now.When trying different things which could lead to invalidation of view
if we don't add the dependency between labels (that the empty label
expression resolves to) and the view, I found another way to
invalidate the view.To reproduce it, run the following statements after running
graph_table.sql tests.
CREATE VIEW v_empty_label AS SELECT * FROM GRAPH_TABLE (g1 MATCH (v
WHERE v.vprop1 = 10) COLUMNS (v.elname));
BEGIN;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v1 DROP LABEL l1;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v2 DROP LABEL l1;
ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v3 DROP LABEL l1;
SELECT * FROM v_empty_label;
ROLLBACK;The three ALTER TABLE statements leave the label behind since it's
associated with the edge tables. The SELECT statement still throws
"ERROR: property "elname" for element variable "v" not found". If we
expand the empty label reference in the transformation phase and
record dependencies between those labels and the view, we get a
different error "ERROR: no property graph element of type "vertex"
has label "l1" associated with it in property graph "g1"". The first
error is a bit obscure compared to the second one. So there's relative
improvement. Myself and Peter thought that the second error is an
artifact of the term "vertex labels" in the standard; a term which is
not properly defined in the standard. There are two solutions1. We create vertex label and edge label as separate objects and
record depdencies accordingly
2. We ignore the term "vertex/edge label" in the standard and handle
labels that exist in property graphs but have no associated element of
required type in the query. I think this will require some corrections
in standard to standardize the outcome of such queries.I will provide patches once we decide which approach to take.
For now I have added a test case exhibiting this behaviour. If we
commit the test, somebody who comes across this behaviour will know
why the current behaviour is the way it is and what's the way forward.
But if we don't commit it, which is ok, they will consider this as
buggy behaviour and report it. I am fine either way.As I mentioned earlier, I am creating patches for all outstanding
issues from the same branch. So the patches attached here do not start
from 0001, but they apply with git am on the latest master for me
without any problem.
0005 - fixes `cache lookup failed for label`
0006 - fixes empty label expression and view behaviour
0007 - issue with labels shared by vertex and edges--
Best Wishes,
Ashutosh Bapat
Hi Ashutosh,
Following up here from [1]/messages/by-id/CAON2xHOYJ+dGZznY+oPyBHdLfRtzThQid5iEc-HOxODs3pb3AA@mail.gmail.com, where I was redirected to this thread,
thanks.
I don't think these are the same bug. I applied v20260601-0005
through 0007 on top of master (90354030b8f) and my test case still
fails the same way:
CREATE TABLE v1 (id int);
CREATE TABLE v2 (id int);
CREATE TABLE x (a int);
CREATE PROPERTY GRAPH g VERTEX TABLES
(v1 KEY (id) LABEL l1, v2 KEY (id) LABEL l2);
SELECT 1 FROM x, GRAPH_TABLE (g MATCH (s IS l1|l2 WHERE s.id = x.a)
COLUMNS (s.id));
ERROR: plan should not reference subplan's variable
I also tested the earlier v20260517 patches (which I understand are
what the unattached 0001-0004 of your series correspond to): same
result. That matches expectations, since everything posted in this
thread touches DDL-time code (dependency.c, propgraphcmds.c), while
this is a planner-time failure on a plain SELECT, with no views or
DDL involved.
The trigger is a lateral reference into the GRAPH_TABLE combined with
a label disjunction resolving to two different element tables. Two
labels on the same table don't trigger it, since that produces a
single path query and no UNION.
Root cause, as far as I can tell: replace_property_refs_mutator()
increments varlevelsup for lateral Vars, which is correct when the
path query becomes the subquery RTE directly. With a multi-table
label disjunction, generate_union_from_pathqueries() wraps the path
queries as subquery RTEs of a new UNION query -- one level deeper --
and nothing compensates, so varlevelsup ends up off by one.
The attached patch (same as in [1]/messages/by-id/CAON2xHOYJ+dGZznY+oPyBHdLfRtzThQid5iEc-HOxODs3pb3AA@mail.gmail.com) runs IncrementVarSublevelsUp()
over each path query in the multiple-pathquery branch of
generate_union_from_pathqueries(). It also adds a SELECT from the
existing customers_us view to graph_table.sql: that view's comment
says it exists to test exactly this lateral + disjunction
combination, but it is currently only passed to pg_get_viewdef and
never executed, which is why the regression tests don't catch this.
The patch is against master and passes make check. On top of your
v20260601 series only the test-file hunks conflict (both append to
graph_table.sql); the code hunk applies cleanly.
Given that, should this be tracked separately rather than in this
thread? Happy to go either way.
[1]: /messages/by-id/CAON2xHOYJ+dGZznY+oPyBHdLfRtzThQid5iEc-HOxODs3pb3AA@mail.gmail.com
Attachments:
v1-0001-Fix-lateral-references-in-GRAPH_TABLE-with-label-.patchapplication/octet-stream; name=v1-0001-Fix-lateral-references-in-GRAPH_TABLE-with-label-.patchDownload+23-1
Hi Ewan,
On Thu, Jun 4, 2026 at 4:52 PM Ewan Young <kdbase.hack@gmail.com> wrote:
I don't think these are the same bug. I applied v20260601-0005
through 0007 on top of master (90354030b8f) and my test case still
fails the same way:
Sorry to redirect you to the wrong thread. Please check [1]/messages/by-id/CAHg+QDfnLzsgjaQ_CiKSpP4JH3MKOiwoawEcCzXa9uYr45yiWw@mail.gmail.com. Hope I
have given you the right one this time :)
When submitting the next report, please check if the issue is already
covered by an existing email thread.
[1]: /messages/by-id/CAHg+QDfnLzsgjaQ_CiKSpP4JH3MKOiwoawEcCzXa9uYr45yiWw@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
Hi Ashutosh,
On Thu, Jun 4, 2026 at 7:46 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
Hi Ewan,
On Thu, Jun 4, 2026 at 4:52 PM Ewan Young <kdbase.hack@gmail.com> wrote:
I don't think these are the same bug. I applied v20260601-0005
through 0007 on top of master (90354030b8f) and my test case still
fails the same way:Sorry to redirect you to the wrong thread. Please check [1]. Hope I
have given you the right one this time :)When submitting the next report, please check if the issue is already
covered by an existing email thread.[1] /messages/by-id/CAHg+QDfnLzsgjaQ_CiKSpP4JH3MKOiwoawEcCzXa9uYr45yiWw@mail.gmail.com
No problem, and thanks for the pointer — this time it is indeed the
same issue. I applied v20260602-0010 on top of master (90354030b8f)
and verified that it fixes my test case as well as an edge-label
variant of it; the graph_table regression test also passes. The fix
is essentially the same as the one I posted (adjusting varlevelsup of
the path queries when they get wrapped as subqueries of the UNION),
just placed in generate_setop_from_pathqueries instead, which also
looks cleaner to me. So please consider my report a duplicate of that
thread.
I will dig the archives more carefully before reporting next time :)
Regards,
Ewan Young
Show quoted text
--
Best Wishes,
Ashutosh Bapat
For now I have added a test case exhibiting this behaviour. If we
commit the test, somebody who comes across this behaviour will know
why the current behaviour is the way it is and what's the way forward.
But if we don't commit it, which is ok, they will consider this as
buggy behaviour and report it. I am fine either way.As I mentioned earlier, I am creating patches for all outstanding
issues from the same branch. So the patches attached here do not start
from 0001, but they apply with git am on the latest master for me
without any problem.
0005 - fixes `cache lookup failed for label`
0006 - fixes empty label expression and view behaviour
0007 - issue with labels shared by vertex and edges
Hi Ashutosh,
I applied and tested the v20260601 patches on top of master, looks good.
One thing I noticed though -- RemoveRelations() in propgraphcmds.c
cleans up orphaned pg_propgraph_property entries, but the condition
doesn't include drop_label:
```diff
diff --git a/src/backend/commands/propgraphcmds.c b/src/backend/commands/propgraphcmds.c
index cc516e27020..7c8f397afbf 100644
--- a/src/backend/commands/propgraphcmds.c
+++ b/src/backend/commands/propgraphcmds.c
@@ -1638,7 +1638,7 @@ AlterPropGraph(ParseState *pstate, const AlterPropGraphStmt *stmt)
} /* Remove any orphaned pg_propgraph_property entries */
- if (stmt->drop_properties || stmt->drop_vertex_tables || stmt->drop_edge_tables)
+ if (stmt->drop_label || stmt->drop_properties || stmt->drop_vertex_tables || stmt->drop_edge_tables)
{
foreach_oid(propoid, get_graph_property_ids(pgrelid))
{
``````sql
postgres@zxm-VMware-Virtual-Platform:~/code/postgres$ psql
psql (19beta1)
Type "help" for help.
postgres=# CREATE PROPERTY GRAPH g1
VERTEX TABLES (
v1
LABEL vl1 PROPERTIES (a, b, c)
LABEL vl2 PROPERTIES (a) LABEL vl3 PROPERTIES (a,b)
);
CREATE PROPERTY GRAPH
postgres=# ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v1 DROP LABEL vl1;
ALTER PROPERTY GRAPH
postgres=# SELECT oid, pgpname FROM pg_propgraph_property WHERE pgppgid = 'g1'::regclass ORDER BY pgpname;
oid | pgpname
--------+---------
111971 | a
111973 | b
111975 | c
(3 rows)
```
After dropping vl1, b and c are still there even though no label
references them anymore. Not sure if this is worth fixing -- thoughts?
--
regards,
Man Zeng
On Thu, Jun 4, 2026 at 7:37 PM zengman <zengman@halodbtech.com> wrote:
For now I have added a test case exhibiting this behaviour. If we
commit the test, somebody who comes across this behaviour will know
why the current behaviour is the way it is and what's the way forward.
But if we don't commit it, which is ok, they will consider this as
buggy behaviour and report it. I am fine either way.As I mentioned earlier, I am creating patches for all outstanding
issues from the same branch. So the patches attached here do not start
from 0001, but they apply with git am on the latest master for me
without any problem.
0005 - fixes `cache lookup failed for label`
0006 - fixes empty label expression and view behaviour
0007 - issue with labels shared by vertex and edgesHi Ashutosh,
I applied and tested the v20260601 patches on top of master, looks good.
One thing I noticed though -- RemoveRelations() in propgraphcmds.c
cleans up orphaned pg_propgraph_property entries, but the condition
doesn't include drop_label:```diff diff --git a/src/backend/commands/propgraphcmds.c b/src/backend/commands/propgraphcmds.c index cc516e27020..7c8f397afbf 100644 --- a/src/backend/commands/propgraphcmds.c +++ b/src/backend/commands/propgraphcmds.c @@ -1638,7 +1638,7 @@ AlterPropGraph(ParseState *pstate, const AlterPropGraphStmt *stmt) }/* Remove any orphaned pg_propgraph_property entries */ - if (stmt->drop_properties || stmt->drop_vertex_tables || stmt->drop_edge_tables) + if (stmt->drop_label || stmt->drop_properties || stmt->drop_vertex_tables || stmt->drop_edge_tables) { foreach_oid(propoid, get_graph_property_ids(pgrelid)) { ``````sql
postgres@zxm-VMware-Virtual-Platform:~/code/postgres$ psql
psql (19beta1)
Type "help" for help.postgres=# CREATE PROPERTY GRAPH g1
VERTEX TABLES (
v1
LABEL vl1 PROPERTIES (a, b, c)
LABEL vl2 PROPERTIES (a) LABEL vl3 PROPERTIES (a,b)
);
CREATE PROPERTY GRAPH
postgres=# ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v1 DROP LABEL vl1;
ALTER PROPERTY GRAPH
postgres=# SELECT oid, pgpname FROM pg_propgraph_property WHERE pgppgid = 'g1'::regclass ORDER BY pgpname;
oid | pgpname
--------+---------
111971 | a
111973 | b
111975 | c
(3 rows)
```After dropping vl1, b and c are still there even though no label
references them anymore. Not sure if this is worth fixing -- thoughts?
b won't be dropped since vl3 references it. But c should get dropped.
It will be interesting to see what happens if someone tries to add a
label with property c afterwards with a different data type - it will
fail, I guess. It's worth fixing for that case if nothing else.
We have gathered 3 issues in this thread, which depend upon each other
either because of code or the test queries. Can you please start a new
thread to discuss this and provide a patch fixing it?
--
Best Wishes,
Ashutosh Bapat
b won't be dropped since vl3 references it. But c should get dropped.
It will be interesting to see what happens if someone tries to add a
label with property c afterwards with a different data type - it will
fail, I guess. It's worth fixing for that case if nothing else.We have gathered 3 issues in this thread, which depend upon each other
either because of code or the test queries. Can you please start a new
thread to discuss this and provide a patch fixing it?
Hi Ashutosh,
You're right, I pasted the wrong test case. I've started a new thread
for this issue with the correct repro and patch. Please see:
/messages/by-id/tencent_76F6ACA2364EAA1E5DBD7A47@qq.com
--
regards,
Man Zeng
