On Fri, Sep 11, 2026 at 8:48 PM Robert Haas <[email protected]> wrote: > > On Fri, Sep 11, 2026 at 7:11 AM Ashutosh Bapat > <[email protected]> wrote: > > AFAIU SQL/PGQ section 9.12, Syntax rule 4, if an element table > > specification does not specify the key, a primary key or a unique key > > is used as that element's key. However, if key columns are specified, > > the syntax rules do not require them to constitute a unique key or > > enforce uniqueness. > > > > AFAIU SQL/PGQ Section 9.14 Syntax rules 9 and 10, if an edge table > > specification does not specify the source and destination key columns, > > they are inferred from the foreign key constraints of the underlying > > table. But if they are specified, the rules do not require them to > > constitute a unique key or enforce uniqueness. > > > > Said that Section 9.12 syntax rule 11.c says that the element > > descriptor created from the element specification should contain "the > > list of columns uniquely identifying a row in ET: ETK.". AFAIU, the > > standard expects the user to enforce uniqueness if they explicitly > > specify key columns. > > > > The element keys and edge keys in a way are "not enforced" primary key > > and foreign key constraints - declarative in nature. > > I don't understand how any of this is relevant to the point I raised.
This is response to the cases you provided about the element keys and commented as below -- quoting from your email > committed feature. Generally, if creating the object requires certain > properties to hold, then later DDL that would cause those properties > to be violated should also be blocked. -- end quote I am mentioning the sections of SQL/PGQ standard which govern the behaviour here and showing you that the implementation is compliant with the standard. Maybe we missed adding comments mentioning the rationale. I have added that as a TODO > > > Please note that PROPERTY ALL COLUMNS does not include columns added > > to the element table in future. > > Sure, but why? That seems like a fairly unintuitive interpretation. Replied to this in an adjacent email. Once SQL/PGQ work is resurrected again, it will be good to review the work and discuss specific items. -- Best Wishes, Ashutosh Bapat
