[CALCITE-4924] REGR_SXX and similar aggregate functions return the wr… #3928
Conversation
| @@ -15,9 +15,17 @@ | |||
| # See the License for the specific language governing permissions and | |||
| # limitations under the License. | |||
| # | |||
| !use post | |||
| values 1; | |||
| !use scott | |||
There was a problem hiding this comment.
This example is for review.
| # [CALCITE-4924] REGR_SXX and similar aggregate functions return the wrong data type | ||
| SELECT | ||
| MONTH(HIREDATE) as "MONTH", | ||
| covar_samp(SAL, COMM) as "COVAR_SAMP(SAL, COMM)", |
There was a problem hiding this comment.
Compared to the previous one, this test can remove the cast.
| RelDataType arg0Type, RelDataType arg1Type) { | ||
| switch (sqlKind) { |
There was a problem hiding this comment.
I'm not sure if this is a reasonable implementation, but from the test cases, it seems feasible.
|
|
Today all Calcite aggregation functions (except COUNT) return the exact same data type as the data that is being aggregated. This behavior is permitted by the standard, and I think it's a reasonable one. From the Oracle documentation I think that Oracle behaves in the same way. Before I can review this PR we have to agree what you think the "correct" behavior is. Maybe this should also be a property of the type system if you really want to emulate multiple databases. |
This is my idea, and I am glad to receive your feedback on this issue. I will also check if other databases adopt a similar approach. |
|
Maybe we should discuss the design in the JIRA ticket, I think that's the expected way. |
|
This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 90 days if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@calcite.apache.org list. Thank you for your contributions. |
…ong data type