Hi,
On Fri, 15 May 2026 at 20:31, Junwang Zhao <[email protected]> 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
v3-0001-SQL-PGQ-Record-dependencies-on-graph-labels-and-p.patch
Description: Binary data
