> Tom Lane writes
>
> In the second place, what the code is doing is dependent on an
> understanding
> of the semantics of IN; I'm not sure it's applicable to, say,
> WHERE outervar > ANY (SELECT innervar FROM ...)
> and it's definitely not applicable to
> WHERE outervar > ALL (SELECT innervar FROM ...)
> In particular, the optimization paths that involve unique-ifying the
> subselect output and then using it as the outer side of a join would
> definitely not work for these sorts of things.
>
I'm not sure if I've understood you correctly in the section above. Are
you saying that these types of queries don't have a meaningful or
defined response? Or just that they wouldn't be very well optimized as a
result of the unique-ifying code changes? Or have I just mis-read the
thread...
My understanding is that in ANSI SQL99, the expression
expression > ALL (subquery)
- is TRUE when expression is greater than every value in the set
of values returned by subquery.
- is TRUE if subquery returns no values.
The expression
expression > ANY (subquery)
- is TRUE when expression is greater than at least one value of
the set of values returned by subquery.
- is FALSE if subsquery returns no values.
(As supported by Oracle 9iv2 and Teradata v2r5.0.)
Best regards, Simon
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
