Hi All, In [1] we discussed many issues related to SQL/PGQ. One of the set of issues was around dependencies. Starting this thread to discuss dependency needs of property graph specifically while it's fresh. I think the discussion here will help the next round of PGQ patches. I am expecting to discuss the ideas now and the interpretation of SQL/PGQ standard's relevant clauses. I am expecting to defer the discussion of actual implementation when SQL/PGQ work is proposed again.
Property graph related catalogs mentioned here can be found in master branch prior to b1f106c80cbeb18d3a0219994d98a51a6eca8ede. 1. Reference based dependency: When a pg_propgraph_label_property entry is created, it creates a pg_propgraph_property entry if one does not exist for a property with a given name. When the last pg_propgraph_label_property entry with a given property name is dropped, the pg_propgraph_property entry for property with that name should get dropped. This is necessary to let a user create a property with the same name but different characteristics in the property graph. Similarly for pg_propgraph_element_label entries, when the first pg_propgraph_element_label entry for a given element label is created, it creates a pg_propgraph_label entry if one does not exist for a label with the given name. When the last pg_propgraph_element_label entry for a given element label is dropped, the pg_propgraph_label entry for that label should get dropped. Since the pg_propgraph_property or pg_propgraph_label entries are created internally to support the property graph infrastructure, we need pg_propgraph_property object to depend upon pg_propgraph_label_property and pg_propgraph_label entry to depend upon pg_propgraph_element_label respectively. This looks more like DEPENDENCY_INTERNAL with reference counting i.e. DEPENDENCY_INTERNAL_REF (a new kind of depdendency). The current implementation used DEPENDENCY_AUTO from pg_propgraph_label and pg_propgraph_property to pg_propgraph_element_label and pg_propgraph_label_property respectively - which doesn't allow us to keep reference counts. 2. Dependency of external objects on components of a property graph According SQL/PGQ standard Section 11.22, syntax rule 4 and section 11.25, syntax rule 7 and section 11.26, syntax rule 8.a along with the CASCADE notes, a property graph, whose component is dropped, can not be referenced in objects external to the property graph. Thus we should register a normal dependency from the external object to the property graph (as against a dependency between external object and the component). 3. Dependency of a component of a property graph on external object According SQL/PGQ standard sections 11.5, 11.7 to 11.18, if a property graph component (a property expression or an element table or expression therein) depends upon an external object which is being dropped, the property graph element containing that component should be dropped. Thus the dependency of a property graph component should be registered as a normal dependency from the property graph element/s to the external object. 4. Combining 2 and 3, the dependency from a component of a property graph to a component of another property graph should be recorded as the dependency from the property graph element of the first property graph to the second property graph. 5. Dependency of edge table on vertex table According to section 11.22, General rules 2, when dropping a vertex table, any edge table connecting that vertex table should be dropped. The rule does not mention RESTRICT or CASCADE. Hence the dependency from edge table to vertex table should be registered as AUTO. 6. Locking a property graph during DROP CASCADE DROP cascading to a property graph component should lock the property graph. A drop can not cascade to a property graph since the property graph by itself doesn't depend upon an external object. However, by point 3, a drop can cascade to a property graph element. It can not cascade to a label or a property directly. Hence we should lock the property graph when searching for dependencies of the property graph element being dropped and verify that the property graph is locked when searching for dependencies of the other types of components. Concretely, AcquireDeletionLock() on a property graph element should take a lock on the property graph. That on other types of property graph components should verify that the property graph is locked since they can be reached only via the parent property graph component. For some objects AcquireDeletionLock() already has a precedence of locking the parent object. 7. Prohibit ALTER TABLE ALTER COLUMN TYPE on a column used in a property expression or as an element key as a not supported feature like some other cases. Reconstructing a property graph to reflect column type would be a separate future project. Currently this reports a misleading error. [1] https://www.postgresql.org/message-id/dqa5mstx5mna3i7s23pdwl4m6bek7gqsgfccef44wjpswizufi@3aa6vzri3cat -- Best Wishes, Ashutosh Bapat
