Re: PGQ catalog representation and pg_dump support

On 2026-08-23 Su 4:41 AM, Taha Naveed wrote:
> Hi,
>
> I also encountered an issue with pg_get_propgraphdef() and pg_dump.
>
> CREATE TABLE wr (
>     id int PRIMARY KEY,
>     x text
> );
>
> CREATE PROPERTY GRAPH gwr
>     VERTEX TABLES (
>         wr PROPERTIES (wr AS whole)
>     );
>
> SELECT pg_get_propgraphdef('gwr'::regclass);
> ERROR:  cache lookup failed for attribute 0 of relation ...
>
> The graph itself works, and the whole row property can be queried
> through GRAPH_TABLE. However, pg_dump also fails because it calls
> pg_get_propgraphdef().
> Reproduced this on PG 19beta3 as well as current master.
>
>

Hi Andres, Taha,

I ran a broader audit using Opus 5 off the back of this thread and can
confirm essentially everything reported here, including Taha's whole-row
crash (that one's a one-line guard — get_attname() needs varattno > 0 before
the shortcut, ruleutils.c:1951).

Two further issues, both more urgent than the dump problems since
neither needs any privilege on the underlying tables:

- AlterPropGraph() never checks its target is actually a property graph.
ALTER PROPERTY GRAPH <any table/view/index/sequence you own> ADD VERTEX
TABLES (...) succeeds and writes catalog rows nobody can read
  back.
- GRAPH_TABLE's rewriter enumerates the full cartesian product of
candidate paths with no bound on breadth. A short EXPLAIN over a
middling multi-element pattern — SELECT on someone else's graph is
enough, or
  just the default TEMP privilege — can OOM the backend bringing down
the postmaster. That one probably belongs first in the queue.

Repro for that one:

 CREATE TEMP TABLE z (id int primary key, s int, t int);
  ALTER TABLE z ADD CONSTRAINT zfk FOREIGN KEY (s) REFERENCES z(id);

  CREATE PROPERTY GRAPH gz
    VERTEX TABLES (z AS v1, z AS v2, z AS v3, z AS v4)
    EDGE TABLES (z AS e1 KEY (id) SOURCE KEY (s) REFERENCES v1 (id)
DESTINATION KEY (t) REFERENCES v1 (id),
                 z AS e2 KEY (id) SOURCE KEY (s) REFERENCES v2 (id)
DESTINATION KEY (t) REFERENCES v2 (id),
                 z AS e3 KEY (id) SOURCE KEY (s) REFERENCES v3 (id)
DESTINATION KEY (t) REFERENCES v3 (id),
                 z AS e4 KEY (id) SOURCE KEY (s) REFERENCES v4 (id)
DESTINATION KEY (t) REFERENCES v4 (id));

  EXPLAIN (COSTS OFF) SELECT count(*) FROM GRAPH_TABLE (gz MATCH
(a1)-[b1]->(a2)-[b2]->(a3)-[b3]->(a4)-[b4]->(a5)-[b5]->(a6) COLUMNS
(a1.id AS c1));

On the AI-assisted items in Andres' third message: the correctness bugs
behind all four hold up, but the privilege-escalation framing attached
to each doesn't survive inspection. No surviving orphan row
carries a relation OID; ExecCheckPermissions() reruns on every
execution, so the relcache-invalidation gap is a plan-staleness issue,
not an auth one; the cross-label lookup is keyed by (elemoid, propid) and
can't cross tables; and replacing a cast or operator already requires
owning the type. Real bugs, not exploitable ones.

On Andres' original question — the pg_attribute rows do look vestigial.
heap.c already carves the rowtype out for propgraphs (and toast tables,
sequences); nobody made the matching carve-out for attributes.
Keeping the pg_class representation overall seems right (the ACL and
relcache-invalidation reuse pays for itself), but three targeted fixes —
the attribute carve-out, a propgraph_open() along the lines
Ashutosh floated and dropped upthread, and giving pg_dump its own
dump-object type instead of riding on DO_TABLE — would close most of
what's turned up here, ordering bug included.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com