Re: Modifying NOT NULL Constraint
От | Dan Wilson |
---|---|
Тема | Re: Modifying NOT NULL Constraint |
Дата | |
Msg-id | 015a01bfd5ca$759d0cc0$db7dfea9@dwilson обсуждение исходный текст |
Ответ на | Modifying NOT NULL Constraint ("Dan Wilson" <phpPgAdmin@acucore.com>) |
Список | pgsql-hackers |
Ok... point taken! I guess the masters always have reasons for why things aren't implemented. -Dan ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Dan Wilson" <dan_wilson@geocities.com> Cc: <pgsql-hackers@postgresql.org> Sent: Wednesday, June 14, 2000 12:31 AM Subject: Re: [HACKERS] Modifying NOT NULL Constraint > "Dan Wilson" <dan_wilson@geocities.com> writes: > > So if I'm understanding this correctly, this would be able to remove the NOT > > NULL constraint, but would not be able to set the NOT NULL constraint. Is > > that correct? > > Oh, you can set attnotnull if you feel like it. My point is just that > nothing much will happen to any existing null values in the column. > It's up to you to check for them first, if you care. > > > If that is correct, are their plans to implement a post-create setting of > > the NOT NULL constraint? > > 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? > > You can implement any of these behaviors for yourself with a couple of > SQL commands inside a transaction, so I'm not sure that I see the need > to have a neatly-wrapped-up ALTER TABLE command that will only do one > of the things you might want it to do. > > regards, tom lane
В списке pgsql-hackers по дате отправления: