Robert Haas writes:
> Am I misreading this, or did you just answer an "either-or" question with
> "yes"?
I meant "Yes, that's an issue."
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Tue, Jul 27, 2010 at 7:16 PM, Tom Lane wrote:
> Daniel Grace 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
>>
Daniel Grace writes:
> One possible concern might be typecasts that aren't a 1:1
> representation. While no two VARCHARs are going to produce the same
> TEXT, this is not true in other cases (1.1::float::integer and
> 1.2::float::integer both produce 1, for instance).
> Off the top of my head, I
On Mon, Jul 19, 2010 at 4:08 PM, Hitoshi Harada wrote:
>
> 2010/7/19 Tom Lane :
> > I looked into the problem reported here:
> > http://archives.postgresql.org/pgsql-bugs/2010-07/msg00119.php
> >
[...]
>
> >
> > 2. Split the processing of aggregates with ORDER BY/DISTINCT so that the
> > sorting/
2010/7/19 Tom Lane :
> I looked into the problem reported here:
> http://archives.postgresql.org/pgsql-bugs/2010-07/msg00119.php
>
> 1. Postpone coercion of the function inputs till after processing of
> the ORDER BY/DISTINCT decoration. This isn't too good because then
> we'll be using the "wrong
I looked into the problem reported here:
http://archives.postgresql.org/pgsql-bugs/2010-07/msg00119.php
The reason it's failing is that when parse_agg.c calls
transformSortClause() to process the ORDER BY, the latter function
fails to match the "t" in ORDER BY to the one in the function's input
ar
