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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-10-28 16:45:14 | Re: Updating FSM on recovery |
Previous Message | Hitoshi Harada | 2008-10-28 16:22:47 | Re: Window Functions: v07 APIs and buffering strateties |