Hi,
Given the things I already found manually, I did a short AI review (Opus 5 and
GPT 5.6 Sol) and they found quite a few more things, just looking at the
dependency stuff. I did briefly look over the reported issues, and they all
looked valid to me:
- 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.
- 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().
- 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
- Edge links omit implicit-cast dependencies
Edge creation may accept an implicit cast but records only the equality
operator. Rewrite reconstructs the cast later. DROP CAST (...) therefore
succeeds, after which GRAPH_TABLE fails.
- Graph/materialized-view cycles are unrestorable
A matview can query graph g, then be added as an element of g. pg_dump
reports an unresolved dependency loop and restore fails because either the
graph or matview must exist first. Property graphs lack the
staged/dummy-definition repair used for ordinary views.
- opclass/opfamily for edge key equality
propgraph_edge_get_ref_keys() uses get_opfamily_member() but only the
dependency on the resulting pg_operator is recorded, not the opfamily.
I suggest doing a broader review of the propgraph code yourselves, if there's
this much to find just around propgraph dependencies, there's probably more.
Greetings,
Andres
