Re: [PATCH] Postpone PROPERTY GRAPH creation in pg_dump to POST-DATA when it depends on a unique constraint

On Sun, May 10, 2026 at 8:08 PM SATYANARAYANA NARLAPURAM
<satyanarlapuram(at)gmail(dot)com> wrote:
>
> Hi Hackers,
>
> A property graph that references a vertex (or edge) table with a
> PRIMARY KEY creates a circular dependency for pg_dump.
>
> When we dump the database with such a table pg_dump emitted a
> 'could not resolve dependency loop' warning and then wrote the
> property graph in PRE-DATA before the ADD CONSTRAINT line that
> creates the required unique index. On a restore, the
> CREATE PROPERTY GRAPH then errored out with 'there is no unique
> constraint matching the key for element ...', leaving the property
> graph silently absent from the restored database.
>
> The fix is to resolve it the same way as for materialized views. When a
> property graph is involved in a multi-object loop with the PRE-DATA boundary,
> break the boundary's dependency on it and postpone the property graph
> into POST-DATA via the existing TableInfo.postponed_def flag (already
> honoured by the section assignment in dumpTableSchema()).
> As part of the change I renamed repairMatViewBoundaryMultiLoop to
> repairPostponableBoundaryMultiLoop. This function now handles both
> matview and and propgraph. Patch includes a test.
>

As far as I understand the element key in a property graph does not
depend upon the primary key or unique constraint. Those constraints if
exist are merely used to create an element key in case a separate KEY
clause is not specified. The constraint can be dropped afterwards. So
the circular dependency mentioned above does not exist. The test added
in the patch fails because it expects ALTER TABLE ... ADD CONSTRAINT
to appear before CREATE PROPERTY. Since the property graph doesn't
depend upon the constraint that assumption is incorrect.

Am I missing something here?

--
Best Wishes,
Ashutosh Bapat