Re: PGQ catalog representation and pg_dump support

Hi,

On 2026-08-22 15:33:01 -0400, Andres Freund wrote:
> - Pretty sure pg_dump's dependency handling for property graphs is
> insufficient?
>
> I see there's code to handle dependencies via pg_propgraph_element, but
> there's also dependencies like pg_propgraph_property.pgtypid? I don't
> immediately see such a dependency would be visible to pg_dump, as
> getDependencies() only additionally queries dependencies via
> pg_propgraph_element
>
> There probably are unhandled dependencies other than
> pg_propgraph_property.pgtypid.

Indeed:

DROP PROPERTY GRAPH IF EXISTS g_dump;
DROP TABLE IF EXISTS zz_rowtab CASCADE;
DROP TABLE IF EXISTS t_dump CASCADE;

CREATE TABLE zz_rowtab (a int, b int);
CREATE TABLE t_dump (id int PRIMARY KEY, txt text);

CREATE PROPERTY GRAPH g_dump
VERTEX TABLES (
t_dump KEY (id) LABEL l PROPERTIES (id, row(1,2)::zz_rowtab AS p)
);

dumps as

CREATE PROPERTY GRAPH public.g_dump
VERTEX TABLES (
public.t_dump KEY (id) LABEL l PROPERTIES (ROW(1, 2)::public.zz_rowtab AS p)
);
...
CREATE TABLE public.zz_rowtab (
a integer,
b integer
);

Which obviously can't work.

This example is the easy case, because they both g_dump and zz_rowtab have the
same priority. But I'm pretty sure that dependencies on other object types,
even if they are in a lower priority class, can still trigger problems when
reordered due to the topo sort.

Greetings,

Andres