From: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su> |
---|---|
To: | Mattias Kregert <matti(at)algonet(dot)se> |
Cc: | ocie(at)paracel(dot)com, pgsql-hackers(at)hub(dot)org |
Subject: | Re: [HACKERS] Subselects and NOTs |
Date: | 1998-02-24 01:30:27 |
Message-ID: | 34F222B3.8282B243@sable.krasnoyarsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mattias Kregert wrote:
>
> ocie(at)paracel(dot)com wrote:
> >
> > On another note, I have been following this "not a in b" vs "not a in
> > b" discussion and it seems to me that the two statements are logically
> > equivalent. Testing for a's membership in the set b and then negating
> > should be equivalent to testing for a's membership in the compliment
> > of set b. In these tests, nulls seem to be treated just like any
> > other value.
> >
> > Ocie
>
> According to the SQL standard: Where 'NOT' and 'IN' are written next to
> each other, this is an alias for "<>ALL", and 'IN' is an alias for
> "=ANY". Therefore:
>
> "a NOT IN b" evaluates as: (a) <>ALL (b)
> "NOT a IN b" evaluates as: NOT ( (a) =ANY (b) )
>
> ...which give these results:
>
> NOT 1 IN 2 true
> 1 NOT IN 2 true
>
> NOT 1 IN NULL true [NOT (1 =ANY NULL)]
> 1 NOT IN NULL false [1 <>ALL NULL]
This is exactly how Postgres works now and differ from 3 "big boys".
If there are no objections then I'll leave this as is. We can return
to this issue latter.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas G. Lockhart | 1998-02-24 02:16:00 | Re: [HACKERS] Subselects and NOTs |
Previous Message | Vadim B. Mikheev | 1998-02-24 01:19:52 | Re: [HACKERS] Open 6.3 issues |