Re: PGQ catalog representation and pg_dump support - Mailing list pgsql-hackers

From Robert Haas
Subject Re: PGQ catalog representation and pg_dump support
Date
Msg-id CA+Tgmobf2V8T7ofUiwX+0AHjNnT+9p=c=wO_Vern9VDYHyEOmA@mail.gmail.com
Whole thread
In response to Re: PGQ catalog representation and pg_dump support  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Fix RLS checks for UPDATE/DELETE FOR PORTION OF leftover rows
Re: PGQ catalog representation and pg_dump support
List pgsql-hackers
On Fri, Sep 11, 2026 at 7:11 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.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



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Logical Implication
Next
From: Sami Imseih
Date:
Subject: Re: Reject WAIT FOR earlier in transaction-snapshot mode