On Tue, Sep 1, 2026 at 8:50 PM Ashutosh Bapat <[email protected]> wrote: > > On Tue, Sep 1, 2026 at 5:20 PM Ashutosh Bapat > <[email protected]> wrote: > > > > On Tue, Sep 1, 2026 at 12:31 PM Ashutosh Bapat > > <[email protected]> wrote: > > > > > > > > > - External cascades leave orphan graph metadata > > > > > > > > > > ALTER PROPERTY GRAPH explicitly removes unused labels/properties, > > > > > but generic > > > > > dependency deletion bypasses that cleanup: > > > > > > > > > > CREATE TABLE v (id int PRIMARY KEY); > > > > > CREATE PROPERTY GRAPH g > > > > > VERTEX TABLES (v LABEL l PROPERTIES (id AS p)); > > > > > DROP TABLE v CASCADE; > > > > > > > > > > g retains global label l and integer property p. Adding a new text > > > > > property named p then incorrectly > > > > > reports a type mismatch. > > > > > > > > > > > > > > > SELECT count(*) AS elements > > > > > FROM pg_propgraph_element > > > > > WHERE pgepgid = 'g'::regclass; > > > > > > > > > > SELECT count(*) AS labels > > > > > FROM pg_propgraph_label > > > > > WHERE pglpgid = 'g'::regclass; > > > > > > > > > > SELECT count(*) AS properties > > > > > FROM pg_propgraph_property > > > > > WHERE pgppgid = 'g'::regclass; > > > > > > > > > > CREATE TABLE v2 (id text PRIMARY KEY); > > > > > > > > > > ALTER PROPERTY GRAPH g > > > > > ADD VERTEX TABLES ( > > > > > v2 LABEL l PROPERTIES (id AS p) > > > > > ); > > > > > > > > > > ERROR: 42601: property "p" data type mismatch: integer vs. text > > > > > DETAIL: In a property graph, a property of the same name has to > > > > > have the same data type in each label. > > > > > > > > > > > > > Thanks for reporting it. I did not find any existing code which deals > > > > with delete-when-reference-drops-to-zero behaviour. Ideally, we should > > > > invent a new kind of dependency that will delete the dependent objects > > > > when the number of references to the object drops to zero. But it's > > > > possibly too late for that kind of change for PG 19 and the semantics > > > > of such a dependency need to be carefully thought through to be > > > > applicable beyond property graphs. We can rework this in a future > > > > release and introduce such a dependency cleanup mechanism. For now, I > > > > am adding a special handling in performDeletion() and > > > > performMultipleDeletions() to collect and delete all the orphaned > > > > property graph objects. To make it easy to convert it entirely driven > > > > by dependency mechanism later, the code in the patch makes use of > > > > pg_depend to find the orphaned property graph objects instead of using > > > > the property graph catalog as much as possible. > > > > > > > > To avoid code duplication, AlterPropGraph() also uses the same > > > > routines to delete orphaned property graph objects. Current > > > > AlterPropGraph() cleans up all the orphaned property graph objects > > > > once per command but it examines every object irrespective of whether > > > > its parent object was deleted or not. With this change we examine only > > > > objects downstream to the objects that are being deleted but it means > > > > we might be doing it multiple times for the same object. Given that > > > > ALTER PROPERTY GRAPH can drop only one parent object at a time, the > > > > probability of that leading to multiple deletions cascading to a > > > > single orphaned object is low. So, I think it's a net win. > > > > > > > > This fix is in 0002 patch which is WIP. I will be working more on it > > > > tomorrow. Early comments are welcome. > > > > > > > > - Similarly, query plan caching is not handled correctly after a > > > > CASCADE style > > > > dropping. > > > > > > > > AlterPropGraph() calls CacheInvalidateRelcacheByRelid(), but that's > > > > not > > > > invoked when done via performDeletion() -> DropObjectById(). > > > > > > > > > > I extended the earlier fix to drop the orphaned property and label > > > entries also to invalidate the caches. > > > > > > Attached patchset has > > > 0001 - a minor code refactoring to help 0004 > > > 0002 - a minor test case comment clarifying intention of the test case > > > 0003 - pg_dump dependency transfer fix > > > 0004 - fixes dropping orphaned property and label entries and also > > > invalidate caches because of cascaded drops. > > > > > > > > > > > - Views depend only on global pg_propgraph_label and > > > > pg_propgraph_property rows > > > > not the specific label/property association. > > > > > > > > > CREATE TABLE v1 (id integer PRIMARY KEY, n integer); > > > CREATE TABLE v2 (id integer PRIMARY KEY, n integer); > > > > > > CREATE PROPERTY GRAPH g > > > VERTEX TABLES ( > > > v1 LABEL l1 PROPERTIES (n AS p) LABEL keep NO PROPERTIES, > > > v2 LABEL l2 PROPERTIES (n AS p) > > > ); > > > > > > CREATE VIEW gv AS > > > SELECT * > > > FROM GRAPH_TABLE ( > > > g MATCH (x IS l1) > > > COLUMNS (x.p) > > > ); > > > > > > ALTER PROPERTY GRAPH g > > > ALTER VERTEX TABLE v1 > > > ALTER LABEL l1 DROP PROPERTIES (p); > > > > > > SELECT to_regclass('gv') AS view_still_exists; > > > SELECT * FROM gv; > > > > > > results in: > > > > > > ERROR: 42704: property "p" for element variable "x" not found > > > > This behaviour is governed by section 11.26, syntax rule 8.a. It says > > If ALTER LABEL action immediately contains DROP PROPERTY then: > > a. If RESTRICT is specified, then SPG (the property graph specified in > > the ALTER PROPERTY GRAPH statement) shall not be referenced in any of > > the following: the list here includes, views, functions, constraints, > > value expressions in other property graph etc. > > b. Note 164 says "If CASCADE is specified, then any such dependent > > object will be dropped by the execution of the revoke statement > > specified in the general rules of this subclause." I did not find any > > revoke statement in section 11.26. Something to fix , but there's a > > revoke statement in DROP PROPERTY GRAPH section. > > > > Interpreting a and b together, in the above case dropping the property > > should not be allowed in RESTRICT mode. In CASCADE mode however, the > > view should be dropped. That's consistent with the other DROP CASCADE > > behaviours.
Closing discussion on dependency related issues of property graph. Since the feature is reverted we can discuss a proper fix for the next round. I will start a new thread to discuss all dependencies together. -- Best Wishes, Ashutosh Bapat
