From: | Wim Ceulemans <Wim(dot)Ceulemans(at)nice(dot)be> |
---|---|
To: | Carolyn Lu Wong <carolyn(at)kss(dot)net(dot)au> |
Cc: | "pgsql-sql(at)postgresql(dot)org" <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: primary key question |
Date: | 2000-07-20 07:45:31 |
Message-ID: | 3976AE1B.C8BD2CEE@nice.be |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Carolyn Lu Wong wrote:
>
> create table aaa(
> field1 .... not null,
> field2 ....,
> ....,
> primary key (field1, field2)
> );
>
> Based on the above table definition, field2 allows null values. But
> after the table created based on the above script, field2 becomes not
> null. The only conclusion I come up with is setting the field as part of
> the primary key, PostgreSQL automatically sets the field to not null. Or
> is it something else?
>
> Is this a feature or bug?
This is in sync with the SQL-92 spec as the following explains:
Quote from Tom Lane on pgsql-general yesterday:
> Two nulls are never considered equal, therefore the unique constraint
> does not trigger.
>
> This is correct behavior according to SQL92 4.10.2:
>
> A unique constraint is satisfied if and only if no two rows in
> a table have the same non-null values in the unique columns. In
> ^^^^^^^^
> addition, if the unique constraint was defined with PRIMARY KEY,
> then it requires that none of the values in the specified column or
> columns be the null value.
>
> (The second sentence just says that PRIMARY KEY implies NOT NULL as well
> as UNIQUE.)
>
> Another way to look at it is that the comparison to see whether the two
> NULLs are equal would yield NULL, and a NULL result for a constraint
> condition is not considered to violate the constraint.
>
> Another way to look at it is that NULL means "I don't know what the
> value is", so if you don't know what the values in two rows really are,
> you don't know whether they're equal either. I suppose you could make
> a case for either accepting or rejecting the UNIQUE constraint in that
> situation --- but SQL92 chose the "accept" decision, and I think that
> for the majority of practical applications they made the right choice.
>
> If you don't like that behavior, possibly your column should be defined
> as NOT NULL.
>
Regards
Wim
From | Date | Subject | |
---|---|---|---|
Next Message | Wim Ceulemans | 2000-07-20 07:55:45 | Re: from not null field to nullable field? |
Previous Message | Carolyn Lu Wong | 2000-07-20 07:26:30 | primary key question |