Re: PGQ catalog representation and pg_dump support

On Sun, Aug 23, 2026 at 1:55 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
>
> - Edge links omit implicit-cast dependencies
>
> Edge creation may accept an implicit cast but records only the equality
> operator. Rewrite reconstructs the cast later. DROP CAST (...) therefore
> succeeds, after which GRAPH_TABLE fails.
>
> - opclass/opfamily for edge key equality
>
> propgraph_edge_get_ref_keys() uses get_opfamily_member() but only the
> dependency on the resulting pg_operator is recorded, not the opfamily.
>

The implementation of property graph edge vertex links is modeled
after foreign key constraints. Foreign key constraints do not record a
dependency on the cast and have the same issue. Similarly for
opfamily. There are no comments explaining why that dependency is
missing. If we need to fix it, we need to fix it for foreign key
constraints as well. I don't think we should fix it for property graph
edges alone. Here's how it behaves in case of FK/PK

CREATE TYPE fk_key AS ENUM ('1', '2');

CREATE FUNCTION key_to_integer(value fk_key) RETURNS integer
LANGUAGE SQL IMMUTABLE STRICT
RETURN value::text::integer;

CREATE CAST (fk_key AS integer)
WITH FUNCTION key_to_integer(fk_key) AS IMPLICIT;

CREATE TABLE pk_parent (id integer PRIMARY KEY);
CREATE TABLE fk_child (parent_id fk_key REFERENCES pk_parent(id));
INSERT INTO pk_parent VALUES (1);
INSERT INTO fk_child VALUES ('1');

DROP CAST (fk_key AS integer);

\c -- this is important otherwise cache is used

INSERT INTO fk_child VALUES ('1');
2026-09-10 15:04:37.981 IST [2069368] ERROR: no conversion function
from fk_key to integer
2026-09-10 15:04:37.981 IST [2069368] STATEMENT: INSERT INTO fk_child
VALUES ('1');
ERROR: no conversion function from fk_key to integer

>
> - Graph/materialized-view cycles are unrestorable
>
> A matview can query graph g, then be added as an element of g. pg_dump
> reports an unresolved dependency loop and restore fails because either the
> graph or matview must exist first. Property graphs lack the
> staged/dummy-definition repair used for ordinary views.
>

This behaviour isn't specific to property graph but a general issue
with materialized views that reference pg_class entries. Consider the
following example:
-- A table can depend on the row type of a materialized view that reads it,
-- creating a dependency loop that pg_dump cannot restore.
CREATE TABLE mvtest_cycle_table (id int);
CREATE MATERIALIZED VIEW mvtest_cycle_mv AS
SELECT id FROM mvtest_cycle_table;
ALTER TABLE mvtest_cycle_table ADD COLUMN mv_value mvtest_cycle_mv;

pg_dump succeeds reporting the cyclic dependency but pg_restore fails
with the following error:
pg_restore: error: could not execute query: ERROR: type
"public.mvtest_cycle_mv" does not exist
994 LINE 20: "mv_value" "public"."mvtest_cycle_mv"

--
Best Wishes,
Ashutosh Bapat