On Tue, 1 Nov 2005, Diego wrote:
> Hi,
> I´m a brazilian programmer!
>
> I have a question about Postgres UNIQUE KEY. Look:
>
> (Step 1)
> CREATE TABLE test (
> id integer not null primary key,
> id_uni integer not null,
> cod integer,
> name varchar(40),
> constraint test_uk unique(id_uni, cod)
> )
>
> (Step 2)
> insert into test (id, id_uni, cod, name)
> values (1, 1, null, 'A')
>
> (Step 3)
> insert into test (id, id_uni, cod, name)
> values (2, 1, null, 'B') =========> [Have the same UNIQUE KEY]
>
> Why postgresql don´t break insertion in this case????
AFAICS, SQL (at least 92) says that those do not violate UNIQUE.
The unique predicate on which the UNIQUE constraint is defined says:
2) If there are no two rows in T such that the value of each column
in one row is non-null and is equal to the value of the cor-
responding column in the other row according to Subclause 8.2,
"<comparison predicate>", then the result of the <unique predi-
cate> is true; otherwise, the result of the <unique predicate>
is false.
The unique constraint for the above is effectively
UNIQUE (SELECT id_uni, col FROM test)
The two rows in question look like
(1,null) and (1,null).
There are no rows in that would make the predicate return false AFAICS.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
