Re: primary key question

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