Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).

On 2024-May-14, Robert Haas wrote:

> On Thu, Mar 7, 2024 at 12:32 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > On 2024-Mar-07, Alvaro Herrera wrote:
> > > Maybe we can add a flag RelationData->rd_ispkdeferred, so that
> > > RelationGetPrimaryKeyIndex returned InvalidOid for deferrable PKs; then
> > > logical replication would continue to not know about this PK, which
> > > perhaps is what we want.  I'll do some testing with this.
> >
> > This seems to work okay.
> 
> There is a CommitFest entry for this patch. Should that entry be
> closed in view of the not-NULL revert
> (6f8bb7c1e9610dd7af20cdaf74c4ff6e6d678d44)?

Uhmm, I didn't realize there was a CF entry.  I don't know why it was
there; this should have been an open item, not a bugfix CF entry.

This had already been committed as 270af6f0df76 (the day before it was
sent to the next commitfest).  This commit wasn't included in the
reverted set, though, so you still get deferrable PKs from
RelationGetIndexList.  I don't think this is necessarily a bad thing,
though these don't have any usefulness as things stand (and if we deal
with PKs by forcing not-null constraints to be underneath, then we won't
need them either).

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Postgres is bloatware by design: it was built to house
 PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)