Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY
От | Tom Lane |
---|---|
Тема | Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY |
Дата | |
Msg-id | 9043.1399507637@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY (David G Johnston <david.g.johnston@gmail.com>) |
Ответы |
Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when
used over a window containing an ORDER BY
|
Список | pgsql-bugs |
David G Johnston <david.g.johnston@gmail.com> writes: > The term "peer" in the first quotation is confusing to me. My understanding > is that "PARTITION BY" defines which rows are "peers" - even if that isn't > the wording used. So now using "peers" in relation to the FRAME clause > confuses the issue. AFAIK we've only used "peers" in this context to mean "rows with equal sort-column values". I don't think we have a specific term for "rows appearing in the same partition", but certainly neither the docs nor the code mean that when they say "peer". [ looks at SQL standard... ] The standard uses "peer" in this way too, so that's where we got the term from. Because of that, I'm unwilling to adopt your suggestion of thinking that "peer" means "member of the same partition". However, it seems like maybe we need to clarify the term some more, eg define what we mean by it in more places. Are there any specific places that you think this should be done? > At minimum the top of 9.3.4 could provide links to, and > descriptions/summaries of, what the other 4 sections cover and why things > are broken out the way they are. The other cross-references could point > back to that section-subsection as a kind of launch point: "Please see > section 3.5.1 for an overview of, and links to, other related sections." No particular objection to doing something like that. > Just some food for thought if anyone is industrious and annoyed enough to > act on it. Not me, at least not in the near future. regards, tom lane
В списке pgsql-bugs по дате отправления: