Re: Modifying NOT NULL Constraint

From: "Stephan Szabo" <sszabo(at)kick(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 19:25:41
Message-ID: 00e101bfd636$53dfb0d0$0c64010a@kick.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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).

> 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.
True, but it would be nice to be able to add a check constraint later, and
as
long as you're doing it, it seems silly to ignore NOT NULL.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2000-06-14 20:43:39 Re: Big 7.1 open items
Previous Message Tom Lane 2000-06-14 19:06:34 Re: 7.0.2 cuts off attribute name