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)
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: