From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dan Wilson" <dan_wilson(at)geocities(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Modifying NOT NULL Constraint |
Date: | 2000-06-14 06:31:07 |
Message-ID: | 13599.960964267@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Dan Wilson" <dan_wilson(at)geocities(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Wilson | 2000-06-14 06:33:29 | Re: Modifying NOT NULL Constraint |
Previous Message | Dan Wilson | 2000-06-14 06:17:32 | Re: Modifying NOT NULL Constraint |