Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY
Date: 2014-05-08 00:07:17
Message-ID: 9043.1399507637@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Stephen Frost 2014-05-08 00:07:26 Re: BUG #10250: pgAdmin III 1.16.1 stores unescaped plaintext password
Previous Message Tom Lane 2014-05-07 23:58:16 Re: BUG #7914: pg_dump aborts occasionally