Re: PGQ catalog representation and pg_dump support

On Fri, Sep 11, 2026 at 8:48 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> 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.

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