"Hitoshi Harada" <umi.tanuki@gmail.com> writes:
> 2008/12/20 Tom Lane <tgl@sss.pgh.pa.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