Re: add more frame types in window functions (ROWS)

>>>>> "Hitoshi" == Hitoshi Harada <umi.tanuki@gmail.com> writes:
>>> (A question here: the spec allows (by my reading) the use of>>> parameters in the window frame clause, i.e. BETWEEN
$1PRECEDING>>> AND $2 FOLLOWING.  Wouldn't it therefore make more sense to treat>>> the values as Exprs, albeit very
limitedones, and eval them at>>> startup rather than assuming we know the node type and digging>>> down into it all
overthe place?) 
>> Seems like you might as well allow any expression not containing>> local Vars.  Compare the handling of LIMIT.
Hitoshi> Hmm, I've read it wrong, was assuming a constant for <unsigned valueHitoshi> specification> which actually
includesany expression. But it's aHitoshi> fixed value during execution, right? Otherwise, we cannot predicateHitoshi>
frameboundary. 

The spec doesn't allow arbitrary expressions there, only literals and
parameters. Allowing more than that would be going beyond the spec, but
as with LIMIT, could be useful nonetheless.

For it to be a fixed value during execution, the same rules apply as
for LIMIT; it can't contain Vars of the current query level.

My thinking is that the executor definitely shouldn't be relying on it
being a specific node type, but should just ExecEvalExpr it on the
first call and store the result; then you don't have to know whether
it's a Const or Param node or a more complex expression.

--
Andrew.