On Tue, Sep 1, 2026 at 11:20 AM Ashutosh Bapat <[email protected]> wrote: > > > However, consider the case below: > > > > CREATE FUNCTION shared_f() RETURNS int LANGUAGE SQL RETURN 1; > > ALTER PROPERTY GRAPH g4 ALTER VERTEX TABLE t1 ADD LABEL shared_l > > PROPERTIES (shared_f() AS shared_p); > > ALTER PROPERTY GRAPH g4 ALTER VERTEX TABLE t2 ADD LABEL shared_l > > PROPERTIES (i AS shared_p); > > DROP FUNCTION shared_f() CASCADE; > > > > DROP FUNCTION would lead to dropping the property shared_p in label > > shared_l of element t1. But the shared_p in label shared_l of element > > t2 remains unaffected, but now the two labels are inconsistent with > > each other. The section 11.26 does not specify directly the outcome of > > this situation. Should DROP FUNCTION be rejected because property > > graph consistency rules fail even if CASCADE is specified? That looks > > inconsistent with how CASCADE mode is applied in other cases. Can you > > please clarify?
[RMT hat] The RMT has been spending time looking at the current state of PGQ given the release time, and we have some serious concerns about the number of design issues with either recently posted patches or without consensus on behavior. The majority of those are in this thread, so I'll summarize my understanding of a few of them that are currently unresolved: Orphaned label/property metadata (External generic CASCADEs (e.g. DROP TABLE ... CASCADE) leave orphan graph metadata): --- These show up as phantom entries in information_schema views, can cause later legitimate alterations of the property graph to fail, and can render the graph undumpable/unrestorable. There is a patch that was posted yesterday (September 1st) that aims to fix this but it is considered a stop-gap measure and not the ideal fix. Others have not weighed in on how effective this stop-gap measure is. And it is acknowledged that the ideal fix is out-of-scope for 19. Global vs per-label scoping of labels and properties: --- A view over a GRAPH_TABLE becomes silently unqueryable after a property/label is dropped from one element when it still exists elsewhere in the graph. Ashutosh has analyzed the standard and has an interpretation of what the correct behavior should be with RESTRICT vs CASCADE, but others have not weighed in. Additionally, there is an unanswered question around what should happen for a function/property shared across two labels. There is not a posted fix for this yet, the desired behavior in some cases is unresolved pending an interpretation of the standard, and there is acknowledgement that a more correct fix is association-granularity dependencies which is out of scope for 19. Whether there should be a pg_class entry for property graphs: --- Andres who posted his initial concern about this has not indicated if the answers resolve his concern. Separately, though having a pg_class entry seems to buy you some functionality for free, the bug Andrew reported where AlterPropGraph() doesn't verify its target is a property graph feels like it may be indicative of more problems related to code that is reading pg_class entries and not distinguishing between graphs and tables. Assorted other issues in this thread: --- Elsewhere in this thread, there are several more dependency ordering problems that don't have proposed fixes yet, for example, the unresolved dependency loop in pg_dump when materialized view queries a GRAPH_TABLE. To be clear, our concern is not a result of having reviewed the uncommitted patches in this thread or PGQ code more broadly. We are most concerned that there are several reported issues that pose design and behavior questions that the community and patch authors have yet to resolve. We feel that if any desired behavior is still unsettled, there is insufficient time to fix these in time for the release. This work is in addition to other reported PGQ bugs that do not involve design issues but that nonetheless need to be fixed before releasing Postgres 19. As such, unless we are misunderstanding something about the discussion, we feel it would be better to revert this in 19. That would take off the time pressure now and would make it easier to fix these things properly in 20 without having to be burdened by backwards compatibility and backpatching. - Melanie
