Thread

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