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

From Alvaro Herrera
Subject Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).
Date
Msg-id 202403051236.to67sdlvgxk6@alvherre.pgsql
Whole thread Raw
In response to Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).
List pgsql-hackers
On 2024-Mar-04, Dean Rasheed wrote:

> I don't think that this is the right fix. ISTM that the real issue is
> that dropping a NOT NULL constraint should not mark the column as
> nullable if it is part of a PK, whether or not that PK is deferrable
> -- a deferrable PK still marks a  column as not nullable.

Yeah.  As I said upthread, a good fix seems to require no longer relying
on RelationGetIndexAttrBitmap to obtain the columns in the primary key,
because that function does not include deferred primary keys.  I came up
with the attached POC, which seems to fix the reported problem, but of
course it needs more polish, a working test case, and verifying whether
the new function should be used in more places -- in particular, whether
it can be used to revert the changes to RelationGetIndexList that
b0e96f311985 did.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"La persona que no quería pecar / estaba obligada a sentarse
 en duras y empinadas sillas    / desprovistas, por cierto
 de blandos atenuantes"                          (Patricio Vogel)

Attachment

pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: type cache cleanup improvements
Next
From: Laurenz Albe
Date:
Subject: Reducing the log spam