Re: Can't find not null constraint, but \d+ shows that
От | Alvaro Herrera |
---|---|
Тема | Re: Can't find not null constraint, but \d+ shows that |
Дата | |
Msg-id | 202404101358.iet3euazs5zf@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Can't find not null constraint, but \d+ shows that (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Can't find not null constraint, but \d+ shows that
Re: Can't find not null constraint, but \d+ shows that |
Список | pgsql-hackers |
It turns out that trying to close all holes that lead to columns marked not-null without a pg_constraint row is not possible within the ALTER TABLE framework, because it can happen outside it also. Consider this CREATE DOMAIN dom1 AS integer; CREATE TABLE notnull_tbl (a dom1, b int, PRIMARY KEY (a, b)); DROP DOMAIN dom1 CASCADE; In this case you'll end up with b having attnotnull=true and no constraint; and no amount of messing with tablecmds.c will fix it. So I propose to instead allow those constraints, and treat them as second-class citizens. We allow dropping them with ALTER TABLE DROP NOT NULL, and we allow to create a backing full-fledged constraint with SET NOT NULL or ADD CONSTRAINT. So here's a partial crude initial patch to do that. One thing missing here is pg_dump support. If you just dump this table, it'll end up with no constraint at all. That's obviously bad, so I propose we have pg_dump add a regular NOT NULL constraint for those, to avoid perpetuating the weird situation further. Another thing I wonder if whether I should use the existing set_attnotnull() instead of adding drop_orphaned_notnull(). Or we could just inline the code in ATExecDropNotNull, since it's small and self-contained. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Postgres is bloatware by design: it was built to house PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
Вложения
В списке pgsql-hackers по дате отправления: