Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases
От | Álvaro Herrera |
---|---|
Тема | Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases |
Дата | |
Msg-id | 202510061043.hjzm5ixk5tfs@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases
|
Список | pgsql-bugs |
On 2025-Oct-06, Dilip Kumar wrote: > While quickly checking this commit, it seems the problem is that > before this commit we had a simple logic to add an additional ALTER > TABLE to SET NULL, if the attribute has a not null constraint but the > the parent from which it is inherited doesn't have not null constraint > [1]. Whereas after this commit, it seems we removed this ALTER > command and tried to add the not null constraint while creating the > inherited table itself, which is fine. But here the logic to identify > whether the constraint is local or not for v17 is not correct [2], it > sets "notnull_islocal", only if the "attislocal" is true, which seems > to be wrong. Because the test case given in this bug the attribute is > not local but it is marked not null. Ah, right, the column is indeed not local, but the constraint is. I think this means we need to use flagInhAttrs to require the constraint to be printed ... looking. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
В списке pgsql-bugs по дате отправления: