Re: Windowing Function Patch Review -> Standard Conformance

"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> 2008/12/20 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> I've been studying the grammar for the windowing patch a bit. It seems
>> to me that the <existing window name> option for <window specification>
>> got left out.

> I completely missed this issue. If the <existing window name> is
> allowed in <window clause>, then does it mean this is possible?

> SELECT row_number() OVER w2 FROM t
> WINDOW w1 AS (PARTITION BY grp), w2(w1)

Yes, I read the spec to allow that. It's a bit pointless unless w2
modifies w1 somehow, though.

> And what if w1 refers to w2 and w2 refers to w1 cyclicly?

Not allowed --- the scope of a window name doesn't include previous
elements of the WINDOW list, so a forward reference isn't valid.

> And from
> what I read the spec, it seems to me that it effects only frame clause
> which is unlikely implemented for 8.4, because if <existing window
> name) is specified then <partition clause> and <order by clause> are
> both permitted in the window definition.

No, you're allowed to substitute a new <order by> clause. The useful
case seems to be that you have a base definition giving a partitioning
and then several derived windows with different orderings and/or
different frame clauses. I'm not really sure why they bothered to set
up the syntax like that, but the spec is pretty clear about it...

>> I am also fairly strongly inclined to rip out all of the frame_clause
>> syntax, since (1) it's unimplemented and unlikely to get implemented
>> for 8.4, and (2) it's not particularly satisfactory anyway.

> The reason I added those grammer was 1) there had been possibilities
> to implement frame clause, and 2) to support not-implemented error. 1)
> is unlikey to be done and for 2) we need only rows/range syntax. So if
> it is annoying for 8.4 release, I don't disagree with your suggestion.

I've been hacking on this and I have a grammar that pretty much works,
but there's some bizarreness around UNBOUNDED. I'll post it later.
There's still a a question whether we should introduce a lot of new
keywords and productions now to support a feature we don't intend to
implement in 8.4. There's a distributed speed cost for each keyword
and each production; I don't really see the argument why users
should pay even a small cost for zero benefit in this release.

regards, tom lane