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

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: add more frame types in window functions (ROWS)
Дата
Msg-id 87eio0mezy.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: add more frame types in window functions (ROWS)  (Hitoshi Harada <umi.tanuki@gmail.com>)
Ответы Re: add more frame types in window functions (ROWS)
Список pgsql-hackers
>>>>> "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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: NULL input for array_agg()?
Следующее
От: Hitoshi Harada
Дата:
Сообщение: Re: add more frame types in window functions (ROWS)