I think the issue is this part:
> What we now realize is that the spec says SUM(outervar) ought to be
> considered an aggregate evaluated at the outervar's query level, and
> then imported *as a whole* as an effective constant for the subquery.
>
> I claim that there should be nothing wrong with
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
>
Tom Lane wrote:
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 sens
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
Wow, a subselect in HAVING. Where do they think up these things. :-)
Yes, it would be nice to support it, though I am not surprised no one
has asked for this feature yet. :-)
---
Tom Lane wrote:
> Some of the Red Hat guy
Tom Lane wrote:
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
G
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);