Re: Modifying NOT NULL Constraint
От | Stephan Szabo |
---|---|
Тема | Re: Modifying NOT NULL Constraint |
Дата | |
Msg-id | 020d01bfd655$0bf43060$0c64010a@kick.com обсуждение исходный текст |
Ответ на | Re: Modifying NOT NULL Constraint (JanWieck@t-online.de (Jan Wieck)) |
Список | pgsql-hackers |
Well, I wasn't planning on doing it any time soon... I just wanted to mention it for completeness-sake since it was my code that does it "wrong" and I'd rather mention it than have someone come back to me asking me why my code does what it does. The basic point is that ALTER TABLE isn't too much of a difference from normal constraint checking... If the constraint fails when the ALTER TABLE is done the statement should abort just like any other statement that causes a constraint failure. > Stephan Szabo wrote: > > > What do you think should happen if there are null values? Refuse the > > > command? Delete the non-compliant rows? Allow the rows to remain > > > even though the column is now nominally NOT NULL? > > > > With ALTER TABLE ADD CONSTRAINT on a non-deferrable NOT > > NULL it should fail. At the end of statement the constraint is not > > satified, > > an exception is raised and the statement is effectively ignored. It's alot > > more complicated for deferrable constraints, and I didn't even actually > > take that into account when I did the foreign key one (because I just > > thought > > of it now). > > Forget it! > > Doing > > BEGIN; > ALTER TABLE tab ADD CONSTRAINT ... INITIALLY DEFERRED; > UPDATE tab SET ... WHERE ... ISNULL; > COMMIT; > > is totally pathetic. Do it the other way round and the ALTER > TABLE is happy. As Tom usually says "if it hurts, don't do > it". We have more important problems to spend our time for.
В списке pgsql-hackers по дате отправления: