Re: PGQ catalog representation and pg_dump support

On Fri, Sep 11, 2026 at 7:11 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> 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.

> 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. If
we decide it is the definitive interpretation, then everything else
needs to play nicely with it. The example I showed demonstrates that
with the current implementation, that's not the case.

--
Robert Haas