Re: Some semantic details of the window-function spec

2008/12/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> * Unlike aggregates, there doesn't seem to be any concept of a window
> function being attached to an outer-level query --- in fact 6.10 rule
> 4 says that a window function's argument can't contain outer references
> at all. That seems excessively strong, but it does seem that there is
> no point in a "winlevelsup" field in WindowFunc, nor in implementing
> any infrastructure for outer-level window functions.

I am so ignorant that I don't know what exactly agglevelsup
represents. Just copied it from agg to window functions... Could
someone show me easy example?

>
> * The last part of section 4.14 states that two different window
> functions must be evaluated against the same sorted row ordering if
> they have syntactically identical partition and ordering clauses,
> even if the windows are otherwise distinct (in particular there
> could be different framing clauses). Since we don't currently implement
> framing clauses the latter is not too interesting, but it's still true
> that the patch as I currently have it doesn't fully meet that
> requirement: if you intentionally specify separate but equivalent named
> window definitions, it won't be smart enough to fold them together,
> and you could end up with extra sorts happening and possibly a different
> ordering of sort-peer rows. How worried are we about that?

Is it? I intended all equivalent windows are folded into one as far as
equal(w1->partitionClause, w2->partitionClause) &&
equal(w1->orderClause, w2->orderClause) is true. And I believe
everytime it's true, we can process them in the same window ordering.
One thing, in the former discussion someone pointed me that we might
have to care about that volatile functions are contained in the
window. I currently don't have any idea about that.

Regards,

--
Hitoshi Harada