From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | david(at)daily-harvest(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15143: Window Functions – Paranthese not allowed before OVER term |
Date: | 2018-04-05 02:40:30 |
Message-ID: | CAKFQuwZWOC5ev8vSwfof3B9RLQxJxj8VxjXtN97hb-x0tZ6aMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Apr 4, 2018 at 7:32 PM, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
wrote:
> > Working as documented:
> >
> > "A window function call always contains an OVER clause directly following
> > the window function's name and argument(s)"
>
> Yeah, how else would the window function know which window clause it
> belongs to?
>
> If you'd done: SELECT (LEAD(col) - LAG(col)) OVER (...) could
> PostgreSQL just assume that you meant to link both the lead and lag to
> the same over clause?
>
Well, if there is only a single aggregate function in the expression there
isn't any ambiguity. If there happened to be more than one the system
could emit a parsing error saying as much. While likely more
user-friendly I don't imagine its worth the headache in the parser.
I did kinda mis-speak earlier though - there probably aren't any
expressions that require a window function to end up in a subquery, but
usually if I get to the point of using complex expressions readability will
lead me to do so.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-04-05 03:02:29 | Re: BUG #15143: Window Functions – Paranthese not allowed before OVER term |
Previous Message | David Rowley | 2018-04-05 02:32:43 | Re: BUG #15143: Window Functions – Paranthese not allowed before OVER term |