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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 7 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJan 23, '04 at 6:37p
activeJan 27, '04 at 5:28p
posts7
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase