On Monday, 29 January 2018, Tom Lane <t...@sss.pgh.pa.us> wrote: > Oliver Ford <ojf...@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.
