Message-ID: <bfdf7b5c-2593-4608-8ba6-b3a8d663166c@dalibo.com>
Date: Fri, 17 Jul 2026 17:27:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19548: Missing dependency between a graph edge and the
 related PK
To: Ayoub Kazar <kazarayoub2004@gmail.com>, pgsql-bugs@lists.postgresql.org
References: <19548-6cac2e96468d7cb8@postgresql.org>
 <CADu+CpRB4nZ-c59Xx30jfW5Vn+3JWSc_b0_+S1GQiwhiLBo9zQ@mail.gmail.com>
Content-Language: en-US, fr-FR
From: Christophe Courtois <christophe.courtois@dalibo.com>
Autocrypt: addr=christophe.courtois@dalibo.com; keydata=
 xsFNBFffvRkBEACz9SwjHcwUpg3Eg+UpuNeuxugWyg555J45Osi7J7m45qubSgxsK41HIgTt
 +bnfcpmi2x4EsygiHUB3sx5eVjr1xVL/nFECBK6uNaKmhckWuTPqiQErbo8UGQw3O3cj0sQc
 oO+OjPzwejh0q9zVHfJ0GcaYHx+RtwMnlQlXYHjalg6OU0YOtgfgiV96pR+ulKjsQR4PNuac
 ShTHwGPceBZn4/HOU5d4HI6swOBeomL3xGpkam9i/8v6rdUNfW39o4lk5NuNkuHIDyc241D0
 MCEVDsjOxJUs0Z+E0Ulth4wdBnyCeH3yX1wfG5IGTZj0qazpte6zVfE97/uea0cMtShOCkyI
 c2faqegQokxPcWCGnIL/QSVI7fdgrQMZmHuDFI+nD7fBf+rPEuYlj+nHBZNJbzJNWVi/J7FK
 y/9ml9bhy9C8eaL5BEw9pxB5gLxKnMabGO1oImr5eUoaLMdDg1bhN6b135+a3DDRNK8D/DBx
 eTjmyv7rrVs7AC6hLGMrF4/K3uYNEsTC7Ord/xZNcUD5SQHqJYyM6ovHlbSrPL+eWIv2AYcS
 lTj2HOULcqyJ8KoExY8y+JnPRxll2qu2intel3F1qhnoZTG1ihUN2f4ywxAS0jHtfAIXcQMy
 idZBKipxOzGx/qUZMHNmmV5KPYPfo431qEM1lRMpZiSPmaMKrwARAQABzT1DaHJpc3RvcGhl
 IENvdXJ0b2lzIChEYWxpYm8pIDxjaHJpc3RvcGhlLmNvdXJ0b2lzQGRhbGliby5jb20+wsF4
 BBMBAgAiBQJX370ZAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRB80jF0dHO1EkU+
 D/9GQlmxrawbtt2Xw7D27BOsLJIp8Ei0u9HlkgSpSf8PdJ4Vj+46zT/GpS3C1aiDr/MZeh9I
 q+P4dtI6BzOYpK76YS3GKzVOLrLAHTOZUZaC8uDg6SPaaAsJ696og1fc50A2vbyn0+bSNqot
 20yCSg1+FaFaRc63Ln2Ya0Us/E+JWLFJocRHmrek6gDFB6N8LOq5usrC4GTapV8zSssnDt5u
 P0DM0lbbjedumhN5pUxJYS4Yvionf3PqtEwyHRoUleDw4QYs/u2pSiFWGSzwNcqQwaPcvUTs
 tbsdV81RbQoFiSgG8P2SbXkhAAiv2i6I/AtSssjTFZy37JTx8o3R0/V+CDW5UD8vjgzllSmo
 CP+WGW4Ailn8GhB3zzJ0iM8uXYJRXn8G695e7vJDu5Vv7Xl5B9BjGtGRiIR4ZzO1EISAoBJM
 V2QWPHRFKzqKAWH55iqWJh8nL6xK+KLJsRE3MvRrNcIlJ/7XFT8eipPIRVXSBHdLfRnbaHTb
 PRxjhArXgydEM2Iskm/m41EB8oGKd0awHUM4dZXqkXpwL94wnSJ20Hb1fjbns/drIrylcyIz
 EfcQsxtms5pb0onEoQCAcKsaH7uimOYWGmbRbMowJBAZbKxVJTrR11iQXBN5K/3Rm8+lYc5w
 Cdn+y26Tq3ud/z4n0cbngRHQYCuTnvpnRIieQ87BTQRX370ZARAA0Vb302mKW8UkVWXhoosu
 /SQ6rnCvpjpZJuKJXbpjKKwYBORSq0SdobK796ooPGn97RDBp0boaTScp0WPnkNaJgUhtd3D
 8FLa+Itzpgsed9LZcMvH9tR6qTQ0syGSyMSt5Z02Uum2pzd4t62eWApE7gvCStxkSbaI9nhO
 yKoSUWSrbmNBJNyqAKmxUrmB0gOfbVJ93RO3g+vziE9FlaBwoYPCxnAIZ61/tV2Fk2TeUotE
 IHp6SN3Ab6J/mzCM9PRzxQDDc07Aq23puZSPJvhxqHnx4HItxZhg/p1VfnvqZ4J1iBGpu/Hl
 RULurFxCX52dy8PYOdo5HA9Nc0icjJqb0qDQVK+/Nb4LPHxvOOW/koaOdzEjaV9t9M1EoZGm
 KA8gd1CQgd1g0oq7nJoYtBAHjg2mcjo9Zi9xuvdUI2biXrxN0eVoKFn8egOBFB0lleclUeR+
 ARE/n/Dpyhf7wA4lKJ4u1wtGbfIx3gyQbJyiU1l6rTDbgUiNryOVYFfJSWPSz+ftBSqdnVxj
 MCrju0ilDGZo6ziBmggwO/zgoxuXXqJ94qPE3NJGxl8ZuvLMMy4OAUpQg3ZFBkAVJmAmwda6
 1d1XGaDTxhRRvpYyNjO3PmD5QVDn76FHoHxxw8ZehqRXC8Dz7BVhoIGACVEM1jkDWGKEESNh
 hr2JY5/4lFWoqgcAEQEAAcLBXwQYAQIACQUCV9+9GQIbDAAKCRB80jF0dHO1EjQpD/wM5A2P
 LSshOUADSCYqzxiroZ/SgB1SkkZjQQb3NBZSDZeN7+NBzdvSxvajmGYOKOtzFYneIJm+l0Gv
 n6fE7KF5FO4kUW7P2wZBVQSPr2sGLJ+R3F0iIjCpuzeSP6dDy5rS9gCltAgBkhEDymztR+C5
 SqhcMMxiLtgYlRBtpZVxs4hCtvu9XaNv0BfdgO8fN4wlyjPmR/HlsEOw1Pyig+5f41FUDn3O
 dYx2oWbPFHuyIORNiDjaLGI2lgaUdPjXbnAKtNJiovNHz+KL6VLbK2YpY/gSW+e1dy+8f1qa
 WCI8l0v0T3XwxePkaS4WVcQABltEkXwhYX6FWWJUYo/AlkbPZVmLae8voOZEvjMQzaBbC8Yp
 UIJI8hK3T3tor+dnPlyTnbfGSdpmDaVA1b37J78RqPbOAFCGfvZ6KfEkYoIF6U4RD8KaEP9P
 BwgF5pldL6y0p2X6JJZc324vITmymdIjitMkjhtobNNaYcSKnpOXC7nimb5ZcYEm2B6LEaDz
 GC1uKYQZH/g1JCtJ7bZppRE293k5E81JPdQ41+pDJneLo1HhYb+pY9ae4vSatsAeADFG2mgE
 P4IUMjM/HHgQCQhcO2O4r3stYmg2hMXPIYl2lGl5OIH+BfFAiTS5DuLx/B0UMXg3iHzBCuKF
 m89092/TMyaRS7j59rFeYxzhLdaHXA==
In-Reply-To: 
 <CADu+CpRB4nZ-c59Xx30jfW5Vn+3JWSc_b0_+S1GQiwhiLBo9zQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/bfdf7b5c-2593-4608-8ba6-b3a8d663166c%40dalibo.com>
Precedence: bulk

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@postgresql.org <mailto: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
>     <mailto: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 <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