| From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: add more frame types in window functions (ROWS) | 
| Date: | 2009-11-15 07:04:21 | 
| Message-ID: | e08cc0400911142304n780c3371vb3c0bb89b0e9216a@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
2009/11/15 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> (A question here: the spec allows (by my reading) the use of
>> parameters in the window frame clause, i.e. BETWEEN $1 PRECEDING AND
>> $2 FOLLOWING.  Wouldn't it therefore make more sense to treat the
>> values as Exprs, albeit very limited ones, and eval them at startup
>> rather than assuming we know the node type and digging down into it
>> all over the place?)
>
> Seems like you might as well allow any expression not containing
> local Vars.  Compare the handling of LIMIT.
Hmm, I've read it wrong, was assuming a constant for <unsigned value
specification> which actually includes any expression. But it's a
fixed value during execution, right? Otherwise, we cannot predicate
frame boundary.
Regards,
-- 
Hitoshi Harada
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hitoshi Harada | 2009-11-15 07:11:19 | Re: add more frame types in window functions (ROWS) | 
| Previous Message | Pavel Stehule | 2009-11-15 06:43:11 | Re: Inspection of row types in pl/pgsql and pl/sql |