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.
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? |