Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Record dependencies on graph labels and properties

  1. (SQL/PGQ) cache lookup failed for label

    zengman <zengman@halodbtech.com> — 2026-05-08T08:39:46Z

    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

  2. Re: (SQL/PGQ) cache lookup failed for label

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-05-12T11:58:48Z

    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] before adding
tests to your patch. With those patches added your test queries above
will throw a different error.

[1] https://www.postgresql.org/message-id/CAExHW5tCCQhgDEfBTKWqe7bDqCUXhPpsqoGipL7Vpf0epcKkXA@mail.gmail.com
-- 
Best Wishes,
Ashutosh Bapat

  3. Re: (SQL/PGQ) cache lookup failed for label

    zengman <zengman@halodbtech.com> — 2026-05-14T14:07:16Z

    > 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] https://www.postgresql.org/message-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

  4. Re: (SQL/PGQ) cache lookup failed for label

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-05-15T10:37:52Z

    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]
> https://www.postgresql.org/message-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

  5. Re: (SQL/PGQ) cache lookup failed for label

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-05-15T10:55:37Z

    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]
>> https://www.postgresql.org/message-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?
>
>
Attaching v2 that uses existing views for test cases.

Regards,
Ayush

  6. Re: (SQL/PGQ) cache lookup failed for label

    Junwang Zhao <zhjwpku@gmail.com> — 2026-05-15T15:01:06Z

    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] https://www.postgresql.org/message-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 view
>>
>> Both 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

  7. Re: (SQL/PGQ) cache lookup failed for label

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-05-15T15:13:15Z

    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 view
> >>
> >> Both 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

  8. Re: (SQL/PGQ) cache lookup failed for label

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-05-17T23:29:30Z

    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 view
>> >>
>> >> Both 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.

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

  9. Re: (SQL/PGQ) cache lookup failed for label

    Junwang Zhao <zhjwpku@gmail.com> — 2026-05-18T00:12:00Z

    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 view
> >> >>
> >> >> Both 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.
>
> 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.


>
>
> --
> Best Wishes,
> Ashutosh Bapat
>

  10. Re: (SQL/PGQ) cache lookup failed for label

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-05-18T00:22:19Z

    On Sun, May 17, 2026 at 5:12 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
>
>
>
> 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 view
>> >> >>
>> >> >> Both 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.
>>
>> 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

  11. Re: (SQL/PGQ) cache lookup failed for label

    Junwang Zhao <zhjwpku@gmail.com> — 2026-05-18T02:07:02Z

    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 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 view
> >> >> >>
> >> >> >> Both 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.
> >>
> >> 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

  12. Re: (SQL/PGQ) cache lookup failed for label

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-05-18T06:26:06Z

    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

  13. Re: (SQL/PGQ) cache lookup failed for label

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-05-21T18:37:15Z

    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