From: | "Dan Wilson" <phpPgAdmin(at)acucore(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Modifying NOT NULL Constraint |
Date: | 2000-06-14 06:33:29 |
Message-ID: | 015a01bfd5ca$759d0cc0$db7dfea9@dwilson |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dan Wilson" <dan_wilson(at)geocities(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Wednesday, June 14, 2000 12:31 AM
Subject: Re: [HACKERS] Modifying NOT NULL Constraint
> "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 | Chris Bitmead | 2000-06-14 06:35:45 | Re: Modifying NOT NULL Constraint |
Previous Message | Tom Lane | 2000-06-14 06:31:07 | Re: Modifying NOT NULL Constraint |