Re: BUG #19548: Missing dependency between a graph edge and the related PK

Hi Christophe,

On Thu, Jul 16, 2026 at 12:38 PM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:

> The following bug has been logged on the website:
>
> Bug reference: 19548
> Logged by: Christophe Courtois
> Email address: christophe(dot)courtois(at)dalibo(dot)com
> PostgreSQL version: 19beta1
> Operating system: Linux Debian 13
> Description:
>
> Hi,
>
> A dependency between a graph and the PK of a relationship
> seems to be missing.
>
> In the following example, a PK on the edge table is compulsory,
> but this PK can be cascade-dropped and the graph is unchanged.
>
> The graph can be dropped later,
> but it cannot be recreated :
> ERROR: no key specified and no suitable primary key exists for definition
> of element "family"
>
> I imagine that a pg_restore will fail too.
>
> Tested on 19~beta2-1~20260629.2015.g9cfd19bc10a.pgdg13+1 from
> apt.postgresql.org
> and 20devel freshly compiled.
>
> Full example :
>
> -- persons
> CREATE TABLE persons (
> id TEXT PRIMARY KEY,
> nom TEXT,
> sexe TEXT
> );
>
> CREATE TABLE family (
> id TEXT PRIMARY KEY,
> spouse1 TEXT REFERENCES persons(id),
> spouse2 TEXT REFERENCES persons(id)
> );
>
> CREATE PROPERTY GRAPH wedding
> VERTEX TABLES (
> persons KEY (id) PROPERTIES ALL COLUMNS
> )
> EDGE TABLES (
> family
> SOURCE KEY (spouse1) REFERENCES persons (id)
> DESTINATION KEY (spouse2) REFERENCES persons (id)
> );
>
> -- Drop the constraint
> -- CASCADE does NOT get rid if the graph
>
> ALTER TABLE family DROP CONSTRAINT family_pkey CASCADE ;
>
> -- The graph is still there
>
> \dG+
>
> -- Recreation fails
>
> DROP PROPERTY GRAPH wedding ;
>
> CREATE PROPERTY GRAPH wedding
> VERTEX TABLES (
> persons KEY (id) PROPERTIES ALL COLUMNS
> )
> EDGE TABLES (
> family
> SOURCE KEY (spouse1) REFERENCES persons (id)
> DESTINATION KEY (spouse2) REFERENCES persons (id)
> );
> ERROR: no key specified and no suitable primary key exists for definition
> of element "family"
> LINE 6: family
>
>
>
>
>
>
>
I checked with Oracle as well to see the behavior and i can confirm its the
same (its a standard thing, see below).

The KEY, either explicit or implicit through the PK is used just at graph
definition time: the catalog just keeps the column numbers in the relative
graph element table (in your case, the family table). There's no dependency
kept.

See:

select * from pg_propgraph_element;
oid | pgepgid | pgerelid | pgealias | pgekind | pgesrcvertexid |
pgedestvertexid | pgekey | pgesrckey | pgesrcref | pgesrceqop | pgedestkey
| pgedestref | pgedesteqop
-------+---------+----------+----------+---------+----------------+-----------------+--------+-----------+-----------+------------+------------+------------+-------------
25282 | 25281 | 25259 | persons | v | 0 |
0 | {1} | | | | |
|
25291 | 25281 | 25265 | family | e | 25282 |
25282 | {1} | {2} | {1} | {96} | {3} | {1}
| {96}
(2 rows)

If a PK was used (your case), it's to deduce what columns uniquely identify
the edge table. What's required is either a KEY clause or an existing PK on
the element table.

The standard itself doesn't mention keeping the dependency (i argue it
should); it only talks about the different cases of the graph element
table's key.

Regards,
Ayoub Kazar