rdblue commented on a change in pull request #24559: [SPARK-27658][SQL] Add FunctionCatalog API URL: https://github.com/apache/spark/pull/24559#discussion_r283508751
########## File path: sql/catalyst/src/main/java/org/apache/spark/sql/catalog/v2/ScalarFunction.java ########## @@ -0,0 +1,41 @@ +/* + * 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.spark.sql.catalog.v2; + +import org.apache.spark.sql.catalyst.InternalRow; +import org.apache.spark.sql.types.DataType; + +/** + * Interface for a function that produces a result value for each input row. + * <p> + * The JVM type of result values produced by this function must be the type used by Spark's + * InternalRow API for the {@link DataType SQL data type} returned by {@link #resultType()}. + * + * @param <R> the JVM type of result values + */ +public interface ScalarFunction<R> extends BoundFunction { + + /** + * Applies the function to an input row to produce a value. + * + * @param input an input row + * @return a result value + */ + R produceResult(InternalRow input); Review comment: I don't think that's a relevant comparison. Clearly, it's a bad idea to copy data into a new `InternalRow` to pass it into a UDF. But `InternalRow` is an interface so we can change how it works. We have an `InternalRow` that exposes data from a `ColumnarBatch` and one that joins partition values, we could similarly have an `InternalRow` that wraps another `InternalRow` for this access. ```scala class ProjectingRow(wrappedPositions: Array[Int]) extends InternalRow { var wrapped = null def set(row: InternalRow): Unit = this.wrapped = row def getInt(pos: Int): Int = wrapped.getInt(wrappedPositions(pos)) ... } ``` Then each UDF call becomes: ```java udfRow.set(inputRow) val result = udf.call(udfRow) ``` And `call` could be implemented as you'd expect: ```java public int call(InternalRow row) { return row.getInt(0) + row.getInt(1) } ``` I think that the overhead of `set` is much better than using reflection or object inspectors like Hive. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
