On Thu, Apr 6, 2017 at 2:49 PM, Bruce Momjian <bruce@momjian.us> wrote:
As part of writing a talk about window functions, I have done some cleanups of the window function docs, attached, that I would like to apply to head.
+1 Overall. Some minor technical items noted below. The only conceptual item is whether (and, if so, how) to deal with partitions vs. frames.
- But unlike regular aggregate functions, use of a window function does not
+ But unlike normal aggregate functions, use of a window function does not
How broadly did you look for usage of normal versus regular? The window function doc page uses "normal" once, vis-a-vis "ordered-set", I haven't looked further. Note on that page the intro paragraph doesn't mention hypothetical-set aggregates as being distinct from ordered-set aggregates yet the tables and the docs here do.
+ treated as a window function and computed across the entire partition.)
Would introducing the concept of frame here trade precision for comprehension?
- <firstterm>window frame</>. Many (but not all) window functions act only
+ <firstterm>window frame</>. Some window functions act only
This is a semantic change as to whether the dominate behavior is to act on frames or partitions. IIUC very few window functions, when presented with a ORDER BY'd OVER and thus a limited frame, will still act on the entire partition instead of the just the frame they are provided. In particular don't all normal aggregates (and user-defined ones) operate on frames? The cume_dist function noted later is one of the few exceptions since it effectively operates on both - the frame for the numerator and the partition for the denominator.
+ aggregate function (i.e. not ordered-set or hypothetical-set aggregates)
I, and others, subscribe to the believe that both i.e., and e.g., should have trailing commas...