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

From Tom Lane
Subject Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY
Date
Msg-id 9043.1399507637@sss.pgh.pa.us
Whole thread Raw
In response to 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>)
Responses Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY  (David Johnston <david.g.johnston@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #7914: pg_dump aborts occasionally
Next
From: Stephen Frost
Date:
Subject: Re: BUG #10250: pgAdmin III 1.16.1 stores unescaped plaintext password