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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #7914: pg_dump aborts occasionally
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: BUG #10250: pgAdmin III 1.16.1 stores unescaped plaintext password