From: | Oliver Ford <ojford(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add RANGE with values and exclusions clauses to the Window Functions |
Date: | 2018-01-29 23:05:39 |
Message-ID: | CAGMVOdtkUxmN8iLF5cQSF7+8kZA_fDYuBBcN0BvjDKbOjCvUdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday, 29 January 2018, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Oliver Ford <ojford(at)gmail(dot)com> writes:
> > On Monday, 29 January 2018, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I've started to go through this in some detail, and I'm wondering why
> >> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
> >> just representing that choice as default (0).
>
> > My guess is that it's a little like putting "ORDER BY x ASC" when ASC is
> > usually default behavior - it adds some documentation, perhaps for people
> > new to SQL or to make your intention more explicit. That's the only
> reason
> > I can think of as to why the standards committee included it.
>
> Yeah, they like to do that. And "ORDER BY x ASC" is actually a precise
> precedent, because we don't print ASC either, cf get_rule_orderby().
>
> regards, tom lane
>
I would strongly suggest taking it out entirely then. There really doesn't
seem a point in adding a new keyword and a new condition in the grammar if
it is going to do absolutely nothing.
If anyone thinks it's useful to have I can just take it out of ruleutils
and remove its define. But personally I would remove it entirely as it's
really just clutter.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-01-29 23:15:51 | Re: JIT compiling with LLVM v9.0 |
Previous Message | Tom Lane | 2018-01-29 22:50:23 | Re: Add RANGE with values and exclusions clauses to the Window Functions |