Re: Add RANGE with values and exclusions clauses to the Window Functions - Mailing list pgsql-hackers

From Oliver Ford
Subject Re: Add RANGE with values and exclusions clauses to the Window Functions
Date
Msg-id CAGMVOdtJZCXQRO1HQvGWTfzxrP0cTtxWXfXJ58EC2f2GgSQ+9w@mail.gmail.com
Whole thread Raw
In response to Re: Add RANGE with values and exclusions clauses to the Window Functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add RANGE with values and exclusions clauses to the Window Functions
List pgsql-hackers


On Monday, 29 January 2018, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Oliver Ford <ojford@gmail.com> writes:
> [ 0001-window-frame-v9.patch ]

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).  As you have it, a
window definition that explicitly specifies EXCLUDE NO OTHERS will be
considered unequal to one that just defaults to that behavior, in
e.g. transformWindowFuncCall().  That seems undesirable, if not
outright wrong.  Against that, having the bit allows ruleutils.c
to print "EXCLUDE NO OTHERS" when the input included that, but that
seems like a wash if not an anti-feature.  We've never been big on
making ruleutils output distinguish explicit from implicit selection
of a default setting, and in this case it could possibly lead to
outputting a query in a form that is not backwards-compatible to
older PG versions, when there's no need to be incompatible.

Exclude No Others does seem pretty pointless to me, but it's in the standard so I included it as an option that can be printed by ruleutils. I can't imagine it being much used, but if people do want to document that they are not excluding other rows they can do so.

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.


If there's some other consideration I'm missing, please say what;
otherwise I'll change it.

BTW, I generally recommend not including a catversion change in
submitted patches.  It causes merge problems any time some other
catversion-bumping patch gets committed, and it can't possibly be
the right value for the final commit since you aren't likely to
be able to predict that date in advance.  It surely doesn't hurt
to remind the committer that a catversion bump is needed, but just
do that in the submission message.

Ok won't do that again. 

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: JIT compiling with LLVM v9.0
Next
From: Andres Freund
Date:
Subject: Re: JIT compiling with LLVM v9.0