From: | mark(at)mark(dot)mielke(dot)cc |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: slow IN() clause for many cases |
Date: | 2005-10-15 11:59:17 |
Message-ID: | 20051015115917.GA11841@mark.mielke.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 14, 2005 at 07:09:17PM -0400, Tom Lane wrote:
> I wrote:
> > I'm thinking that IN should be
> > converted to a ScalarArrayOpExpr, ie
> > x = ANY (ARRAY[val1,val2,val3,val4,...])
> Actually, there is one little thing in the way of doing this: it'll
> fail if any of the IN-list elements are NULL, because we have not got
> support for arrays with null elements. So we'd have to fix that first.
Hey Tom.
Obviously your area of expertise, so please tell me where I'm wrong -
But doesn't "x IN (NULL)" already fail to ever match, similar to "x
= NULL"? (Assuming that compatibility switch isn't enabled)
So, I'd hope people weren't using such an expression? :-) Or is that
not good enough? What does NULL::text[] turn into? An empty string? Is
that the danger? It might match against an empty string?
Cheers,
mark
--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-10-15 14:04:52 | Re: A costing analysis tool |
Previous Message | Satoshi Nagayasu | 2005-10-15 11:02:37 | Re: LDAP Authentication? |