Property graph, dependencies

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