Re: BUG #19548: Missing dependency between a graph edge and the related PK - Mailing list pgsql-bugs

From Ayoub Kazar
Subject Re: BUG #19548: Missing dependency between a graph edge and the related PK
Date
Msg-id CADu+CpRB4nZ-c59Xx30jfW5Vn+3JWSc_b0_+S1GQiwhiLBo9zQ@mail.gmail.com
Whole thread
Responses Re: BUG #19548: Missing dependency between a graph edge and the related PK
Re: BUG #19548: Missing dependency between a graph edge and the related PK
List pgsql-bugs
Hi Christophe,

On Thu, Jul 16, 2026 at 12:38 PM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:

Bug reference:      19548
Logged by:          Christophe Courtois
Email address:      christophe.courtois@dalibo.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

pgsql-bugs by date:

Previous
From: Rafia Sabih
Date:
Subject: Re: Two issues with REFRESH MATERIALIZED VIEW CONCURRENTLY
Next
From: Kenny Chen
Date:
Subject: Re: BUG #19547: libpqrcv_create_slot dereferences NULL on a malformed CREATE_REPLICATION_SLOT reply