From: | "Dean Gibson (DB Administrator)" <postgresql3(at)ultimeth(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Null comparisons (was Re: checksum) |
Date: | 2004-09-27 20:08:34 |
Message-ID: | 5.1.0.14.2.20040927130632.0518ac40@imaps.mailpen.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Even simpler: COALESCE( a = b, a IS NULL AND b IS NULL )
-- Dean
Greg Stark wrote on 2004-09-27 08:17:
>Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
>
> > > On Sun, 26 Sep 2004 20:16:52 +0200, David Helgason <david(at)uti(dot)is> wrote:
> >
> > > > On a similar note, I've found myself wanting an extended '=' operator
> > > > meaning
> > > > (a = b or (a is null and b is null))
> >
> > The original does appear to be equivalent to "not(a is distinct from b)",
> > although I'm not sure that's necessarily easier to use than the above.
>
>I often do things like "coalesce(a,0) = coalesce(b,0)".
>(Or whatever value you know won't appear)
>
>Though for pretty small values of "often". It always makes me think twice
>about my data model when I find myself doing this. But there are definitely
>still cases where it's useful and as clean as anything else I could think of.
>
>--
>greg
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
From | Date | Subject | |
---|---|---|---|
Next Message | David Helgason | 2004-09-27 21:05:59 | Re: Null comparisons (was Re: checksum) |
Previous Message | Shawn Chisholm | 2004-09-27 19:19:47 | Foreign key order evaluation |