Skip site navigation (1) Skip section navigation (2)

Re: Parsing of aggregate ORDER BY clauses

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Grace <dgrace(at)wingsnw(dot)com>, pgsql-hackers(at)postgresql(dot)org, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Subject: Re: Parsing of aggregate ORDER BY clauses
Date: 2010-07-27 23:38:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jul 27, 2010 at 7:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Grace <dgrace(at)wingsnw(dot)com> writes:
>>  But if we SELECT
>> SOME_INTEGER_AGGREGATE(DISTINCT floatcol ORDER BY floatcol), should
>> the DISTINCT operate on floatcol (i.e. 1.1 and 1.2 are distinct, even
>> if it means the function is called with '1' twice) or
>> floatcol::integer (1.1 and 1.2 are not distinct)?
> Yes.  The current implementation has the advantage that any
> unique-ifying step is guaranteed to produce outputs that are distinct
> from the point of view of the aggregate function, whereas if we try to
> keep the two operations at arms-length, then either we lose that
> property or we sort-and-unique twice :-(.

Am I misreading this, or did you just answer an "either-or" question with "yes"?

Robert Haas
The Enterprise Postgres Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-07-27 23:41:29
Subject: Re: Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function
Previous:From: David FetterDate: 2010-07-27 23:33:25
Subject: Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group