Skip site navigation (1) Skip section navigation (2)

Re: Window Functions: v07 APIs and buffering strateties

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>,ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Window Functions: v07 APIs and buffering strateties
Date: 2008-10-28 17:37:23
Message-ID: 20081028173723.GA17203@svana.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Oct 28, 2008 at 12:38:09PM -0400, Tom Lane wrote:
> "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> > In window specifications, we have
> 
> > OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
> 
> > and currently "ROWS" is not reserved so bison is confused with cases
> > of "ROWS" included in expr_list and in FRAME clause. Because there is
> > no delimiter between ORDER BY clause and FRAME (that is (ROWS |
> > RANGE)) clause, "ROWS" can be in expr_list as a_expr.
> 
> Right offhand, I don't see any alternative but to make both ROWS and
> RANGE reserved.  It's pretty annoying since that might break existing
> applications that have been using these as identifiers, but the SQL
> committee seems to care little about that :-(

Given that the only problematic case is if expr_list ends with a
postfix operator, wouldn't it be sufficient to simply decree that in
that case you need parentheses? Seems a lot less painful than adding
two reserved words.

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog(at)svana(dot)org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while 
> boarding. Thank you for flying nlogn airlines.

In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2008-10-28 17:46:42
Subject: Re: PostgreSQL + Replicator developer meeting 10/28
Previous:From: Tom LaneDate: 2008-10-28 17:36:30
Subject: Re: Updating FSM on recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group