Re: slow IN() clause for many cases - Mailing list pgsql-hackers

From mark@mark.mielke.cc
Subject Re: slow IN() clause for many cases
Date
Msg-id 20051015115917.GA11841@mark.mielke.cc
Whole thread Raw
In response to Re: slow IN() clause for many cases  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: slow IN() clause for many cases
List 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@mielke.cc / markm@ncf.ca / markm@nortel.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
bindthem...
 
                          http://mark.mielke.cc/



pgsql-hackers by date:

Previous
From: Satoshi Nagayasu
Date:
Subject: Re: LDAP Authentication?
Next
From: Martijn van Oosterhout
Date:
Subject: Re: A costing analysis tool