Daniel Grace dgr...@wingsnw.com 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
On Tue, Jul 27, 2010 at 7:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Grace dgr...@wingsnw.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
Robert Haas robertmh...@gmail.com 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
On Mon, Jul 19, 2010 at 4:08 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/7/19 Tom Lane t...@sss.pgh.pa.us:
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
2010/7/19 Tom Lane t...@sss.pgh.pa.us:
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
