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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).
Дата
Msg-id 202403051236.to67sdlvgxk6@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Ответы Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список 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)

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: type cache cleanup improvements
Следующее
От: Laurenz Albe
Дата:
Сообщение: Reducing the log spam