Re: Window Functions: v07 APIs and buffering strateties
| От | Tom Lane |
|---|---|
| Тема | Re: Window Functions: v07 APIs and buffering strateties |
| Дата | |
| Msg-id | 8289.1225211889@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Window Functions: v07 APIs and buffering strateties ("Hitoshi Harada" <umi.tanuki@gmail.com>) |
| Ответы |
Re: Window Functions: v07 APIs and buffering strateties
Re: Window Functions: v07 APIs and buffering strateties |
| Список | pgsql-hackers |
"Hitoshi Harada" <umi.tanuki@gmail.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
В списке pgsql-hackers по дате отправления: