Re: BUG #15143: Window Functions – Paranthese not allowed before OVER term

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.

In response to

Responses

Browse pgsql-bugs by date

  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