Bruce Momjian <[EMAIL PROTECTED]> writes:
> When we considered outervar1 as a constant, we could do the aggregate in
> the subquery using computations, but when SUM(outervar1) is computed in
> an above query, combining that with anything that is part of different
> query level makes no sense to me
I wrote:
> Now I finally understand why the spec has all that strange verbiage
> about outer references in set-function arguments. This is the case
> they're talking about. (I don't much like their restriction to a single
> outer reference ... seems like it would be appropriate to allow multiple
>
Jan Wieck <[EMAIL PROTECTED]> writes:
> What is SUM(up1levelvar + up2levelsvar) considered to be? Would that be
> the same as SUM(localvar + outervar) one level up?
Exactly. The spec says that SUM(up1levelvar) is the same as
SUM(localvar) one level up, so this seems a natural generalization.
It
Some of the Red Hat guys have been trying to work through the NIST SQL
compliance tests. So far they've found several things we already knew
about, and one we didn't:
-- TEST:0434 GROUP BY with HAVING EXISTS-correlated set function!
SELECT PNUM, SUM(HOURS) FROM WORKS
GROUP BY PNUM
Jan Wieck <[EMAIL PROTECTED]> writes:
> Would
> SELECT PNUM, SUM(HOURS) FROM WORKS
>GROUP BY PNUM
>HAVING EXISTS (SELECT PNAME FROM PROJ
> WHERE PROJ.PNUM = WORKS.PNUM AND
> AVG(WORKS.HOURS) > PROJ.MAGIC / 200);
