[ 
https://issues.apache.org/jira/browse/FLINK-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278185#comment-15278185
 ] 

ASF GitHub Bot commented on FLINK-3754:
---------------------------------------

Github user fhueske commented on a diff in the pull request:

    https://github.com/apache/flink/pull/1958#discussion_r62682619
  
    --- Diff: 
flink-libraries/flink-table/src/main/scala/org/apache/flink/api/table/expressions/mathExpressions.scala
 ---
    @@ -0,0 +1,147 @@
    +/*
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *     http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +package org.apache.flink.api.table.expressions
    +
    +import org.apache.calcite.rex.RexNode
    +import org.apache.calcite.sql.fun.SqlStdOperatorTable
    +import org.apache.calcite.tools.RelBuilder
    +
    +import org.apache.flink.api.common.typeinfo.BasicTypeInfo._
    +import org.apache.flink.api.common.typeinfo.TypeInformation
    +import org.apache.flink.api.table.typeutils.TypeCheckUtils
    +import org.apache.flink.api.table.validate.ExprValidationResult
    +
    +case class Abs(child: Expression) extends UnaryExpression {
    +  override def dataType: TypeInformation[_] = child.dataType
    +
    +  override def validateInput(): ExprValidationResult =
    +    TypeCheckUtils.assertNumericExpr(child.dataType, "Abs")
    +
    +  override def toString(): String = s"abs($child)"
    +
    +  override def toRexNode(implicit relBuilder: RelBuilder): RexNode = {
    +    relBuilder.call(SqlStdOperatorTable.ABS, child.toRexNode)
    +  }
    +}
    +
    +case class Ceil(child: Expression) extends UnaryExpression {
    +  override def dataType: TypeInformation[_] = LONG_TYPE_INFO
    +
    +  override def validateInput(): ExprValidationResult =
    +    TypeCheckUtils.assertNumericExpr(child.dataType, "Ceil")
    +
    +  override def toString(): String = s"ceil($child)"
    +
    +  override def toRexNode(implicit relBuilder: RelBuilder): RexNode = {
    +    relBuilder.call(SqlStdOperatorTable.CEIL, child.toRexNode)
    +  }
    +}
    +
    +case class Exp(child: Expression) extends UnaryExpression {
    +  override def dataType: TypeInformation[_] = DOUBLE_TYPE_INFO
    +
    +  // TODO: this could be loosened by enabling implicit cast
    +  override def validateInput(): ExprValidationResult = {
    +    if (child.dataType == DOUBLE_TYPE_INFO) {
    --- End diff --
    
    Why do `Exp`, `Log10`, `Ln`, and `Power` require `Double` types? Shouldn't 
all numeric types be supported for these functions?


> Add a validation phase before construct RelNode using TableAPI
> --------------------------------------------------------------
>
>                 Key: FLINK-3754
>                 URL: https://issues.apache.org/jira/browse/FLINK-3754
>             Project: Flink
>          Issue Type: Improvement
>          Components: Table API
>    Affects Versions: 1.0.0
>            Reporter: Yijie Shen
>            Assignee: Yijie Shen
>
> Unlike sql string's execution, which have a separate validation phase before 
> RelNode construction, Table API lacks the counterparts and the validation is 
> scattered in many places.
> I suggest to add a single validation phase and detect problems as early as 
> possible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to