Re: cataloguing NOT NULL constraints
От | Alvaro Herrera |
---|---|
Тема | Re: cataloguing NOT NULL constraints |
Дата | |
Msg-id | 202402050950.q367e2d6rtjs@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: cataloguing NOT NULL constraints (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: cataloguing NOT NULL constraints
Re: cataloguing NOT NULL constraints Re: cataloguing NOT NULL constraints |
Список | pgsql-hackers |
On 2024-Feb-05, Alvaro Herrera wrote: > Hmm, let me have a look, I can probably get this one fixed today before > embarking on a larger fix elsewhere in the same feature. You know what -- this missing CCI has a much more visible impact, which is that the attnotnull marker that a primary key imposes on a partition is propagated early. So this regression test no longer fails: create table cnn2_parted(a int primary key) partition by list (a); create table cnn2_part1(a int); alter table cnn2_parted attach partition cnn2_part1 for values in (1); Here, in the existing code the ALTER TABLE ATTACH fails with the error message that ERROR: primary key column "a" is not marked NOT NULL but with the patch, this no longer occurs. I'm not sure that this behavior change is desirable ... I have vague memories of people complaining that this sort of error was not very welcome ... but on the other hand it seems now pretty clear that if it *is* desirable, then its implementation is no good, because a single added CCI breaks it. I'm leaning towards accepting the behavior change, but I'd like to investigate a little bit more first, but what do others think? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Вложения
В списке pgsql-hackers по дате отправления: