Re: Modifying NOT NULL Constraint

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

In response to

Browse pgsql-hackers by date

  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