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

Le 16/07/2026 à 14:13, Ayoub Kazar a écrit :
> Hi Christophe,
>
> On Thu, Jul 16, 2026 at 12:38 PM PG Bug reporting form
> <noreply(at)postgresql(dot)org <mailto: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
> <mailto: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 <http://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.

Thanks for the explanation!

In fact I can see in pg_get_propgraphdef() that the graph definition is
correctly stored with a KEY (id).

I should have checked the result of pg_dump/pg_restore,
I would have probably found this explanation.

Sorry for the noise.

Yours,

SELECT pg_get_propgraphdef ('wedding'::regclass);

pg_get_propgraphdef

----------------------------------------------------------------------------------------------------------------------------------------------------------
CREATE PROPERTY GRAPH public.wedding

+
VERTEX TABLES (

+
persons KEY (id) PROPERTIES (id, nom, sexe)

+
)

+
EDGE TABLES (

+
family KEY (id) SOURCE KEY (spouse1) REFERENCES persons (id)
DESTINATION KEY (spouse2) REFERENCES persons (id) PROPERTIES (id,
spouse1, spouse2)+
)

--
_________ ____
| || | Christophe Courtois
| ||__ | Consultant DALIBO
| | | | 43, rue du Faubourg Montmartre
| - | / / 75009 Paris
|___| |___| \/ www.dalibo.com