Re: PGQ catalog representation and pg_dump support

On Tue, Sep 1, 2026 at 11:20 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> 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