Re: disallowing multiple NULLs in a unique constraint

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: disallowing multiple NULLs in a unique constraint
Date: 2004-05-12 14:00:40
Message-ID: Pine.LNX.4.33.0405120759490.25767-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 12 May 2004, Peter Eisentraut wrote:

> Am Montag, 9. Februar 2004 06:06 schrieb David Garamond:
> > SQL Server only allow one NULL in a unique constraint column (it's the
> > unique index that does that, so the unique constraint behaves like that
> > too). The question is, what is the best way to simulate that behaviour
> > in Postgres? Can a CHECK constraint does that? Will a trigger with
> > SELECT count(*) ... WHERE f IS NULL be too slow if the table is large?
>
> You can time that yourself (but I suspect it won't be pretty), but I think
> that you're going to have all kinds of other problems if you base your
> database schema on the assumption that NULL = NULL. Better fix the
> application.

It's important to make the point here that SQL Server is broken in this
respect, both in terms of set theory, and the SQL spec definition of how
NULLs behave.

The better option would be to use something other than NULL for this.
I.e. use the characters 'N/A' or something.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Oleg Bartunov 2004-05-12 14:21:47 Re: Cache lookup failure for pg_restore?
Previous Message scott.marlowe 2004-05-12 13:49:14 Re: Is Linux 2.6.5 kernel good enough for production?