should the CORR function return some numeric type that allows fractions?

[monetdb-team]

Date: 2017-04-16 16:40:13 +0200
From: Anthony Damico <>
To: SQL devs <>
Version: 11.25.15 (Dec2016-SP3)
CC: ajdamico, @njnes

Last updated: 2017-10-26 14:01:43 +0200

Comment 25244

Date: 2017-04-16 16:40:13 +0200
From: Anthony Damico <>

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build Identifier:

hi, here's a minimal example.. CORR appears to return the same type as the first argument but i'm not sure it should ever return an integer?

Reproducible: Always

Steps to Reproduce:

CREATE TABLE x ( a DOUBLE , b DOUBLE );
INSERT INTO x VALUES (1.0,2.0);
INSERT INTO x VALUES (2.0,3.0);
SELECT * FROM x;

SELECT CORR( a , b ) FROM x;
SELECT CORR( a , CAST( b AS INTEGER ) ) FROM x;
SELECT CORR( CAST( a AS INTEGER ) , b ) FROM x;

Actual Results:

returns same type as first argument

Expected Results:

return some type with decimals

thanks

Comment 25652

Date: 2017-09-20 09:54:08 +0200
From: @njnes

seems a bug in the auto coersion of inputs of the aggregate function. In the example case(s) we would expect always a double result type. If however both inputs are changed into integers we would (should) use that output time.

Comment 25657

Date: 2017-09-20 11:13:35 +0200
From: MonetDB Mercurial Repository <>

Changeset ac56f9c146f1 made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=ac56f9c146f1

Changeset description:

fixed bug #6287, ie incase of numeric multi argument aggregators up
cast all arguments to the largest type, when resolving the aggregator.

Comment 25658

Date: 2017-09-20 11:22:27 +0200
From: MonetDB Mercurial Repository <>

Changeset d6e71ec46d34 made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=d6e71ec46d34

Changeset description:

add test for bug #6287