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 16221.1399514921@sss.pgh.pa.us
Whole thread Raw
In response to 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 Johnston <david.g.johnston@gmail.com> writes:
> On Wed, May 7, 2014 at 8:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ 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".

> I guess rows falling into the same partition could be deemed "member" rows;
> as in having membership in the partition.

Works for me.

> Does the standard provide a word for tuples that get placed into the same
> partition?

Not that I noticed, but I didn't search hard.

The index of SQL:2011 has one entry for "peer", pointing to this
definition under 10.10 <sort specification list>:

i) Two rows that are not distinct with respect to the <sort
   specification>s are said to be peers of each other. The relative
   ordering of peers is implementation-dependent.

so in their usage it's not even specific to windows.  The terminology
for windows seems to be mostly defined in 4.15.14, and I don't see
a term in there for the rows belonging to a partition.

            regards, tom lane

pgsql-bugs by date:

Previous
From: David Johnston
Date:
Subject: Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY
Next
From: Jeff Davis
Date:
Subject: Re: can insert timestamp value that can't be read