> ERROR: 42P17: no key specified and no suitable primary key exists for > definition of element "person_knows_person" > LINE 6: Person_knows_person > ^ > LOCATION: propgraph_element_get_key, propgraphcmds.c:334 > Time: 0.459 ms > ------8<------------8<------------8<------------8<------------8<------------8<------------8<------ > > It worked when I changed person_knows_person.person1id into PRIMARY KEY.
Yes, each element is expected to have a key, either defined explicitly when creating the graph or implicitly via its primary key.
Right. Per SQL/PGQ Subclause 9.12 "Creation of an element table descriptor", Syntax Rule 4:
a) If <element table key clause> is not specified, then i) If the table descriptor of ET includes a unique constraint descriptor UCD that specifies PRIMARY KEY, then let ETK be the list of the names of the unique columns included in UCD in order of their ordinal position in ET. ii) Otherwise, the table descriptor of ET shall include a preferred candidate key. Let ETK be the list of columns in that preferred candidate key in order of their ordinal position in ET.
b) Otherwise, let ETK be the <column name list> simply contained in <element table key clause>.
Note: our current implementation only checks for PRIMARY KEY when no KEY clause is specified. The standard also allows falling back to a "preferred candidate key", which we don't support yet.
I'm not sure whether we should infer the key from the source and destination keys, though it's doable.
"Preferred candidate key" is likely defined in SQL Foundation (Part 2), which I don't have access to -- I suspect it refers to a UNIQUE NOT NULL constraint. But if the source + destination key columns happen to qualify as one, they would already be covered by rule 4.a.ii above. So rather than special-casing source + destination inference, implementing preferred candidate key support would cover that case naturally.
