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

Re: Window Functions: v07 APIs and buffering strateties

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>
Cc: "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 16:38:09
Message-ID: 8289.1225211889@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> Can "ROWS" be reserved_keyword?

> 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 :-(

BTW, finding this sort of problem is exactly why ignoring shift/reduce
conflicts is a bad idea.  You would've ended up with unexpected
behaviors given the wrong input.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-10-28 16:45:14
Subject: Re: Updating FSM on recovery
Previous:From: Hitoshi HaradaDate: 2008-10-28 16:22:47
Subject: Re: Window Functions: v07 APIs and buffering strateties

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