Re: 8.1 Unique Index Issue/Bug???

On Thu, 2006-07-13 at 09:40, Chris Hoover wrote:
> I am having what appears to be a bug with unique indexes on 8.1.3.
>
> I have created a new table.
>
> create table payer_835 (
> payer_id int8 not null default
> nextval('payer_835_payer_id_seq'::regclass) primary key,
> payer_name varchar(50) not null,
> payer_trn03 varchar(10) not null,
> payer_trn04 varchar(30),
> sku_id int8 references skucode(sku_id) on delete
> cascade on update cascade,
> payer_billable boolean not null default true,
> create_timestamp timestamp not null default now(),
> last_mod_timestamp timestamp,
> expire_timestamp timestamp
> );
>
> On this table, I have created a unique index on payer_trn03,
> payer_trn04, and expire_timestamp. However, since the
> expire_timestamp is normally null, the unique index does not appear to
> be working. I have been able to enter two identical rows into this
> table.
>
> Why is PostgreSQL not enforcing this index? This appears to be a
> pretty major a bug? It would seem that you could have a unique index
> across columns that might have a null in them.
>
> Here is the data from the table:
>
> COPY payer_835 (payer_id, payer_name, payer_trn03, payer_trn04,
> sku_id, payer_billable, create_timestamp, last_mod_timestamp,
> expire_timestamp) FROM stdin;
> 1 CAHABA GBA-AL PART B 1630103830 \N 1
> t 2006-07-13 09:57: 52.834631 \N \N
> 2 FEP 123456789 00402 1 t 2006-07-10
> 10:56:23 \N \N
> 3 NC Medicaid 123123123 \N 1 t
> 2006-07-10 10:56:41 \N \N
> 4 CAHABA GBA-AL PART B 1630103830 \N 1
> t 2006-07-11 16:13:43.808181 2006-07-12
> 10:09:46.066204 \N
> \.
>
>
> Notice records 1 and 4 have identical data (as far as my unique index
> is concerned), and the index it not complaining.

But you have NULL expire_timestamps, and NULL <> NULL