aboutsummaryrefslogtreecommitdiff
path: root/R/create-docs.sh
diff options
context:
space:
mode:
authorMichael Armbrust <michael@databricks.com>2015-08-24 18:10:51 -0700
committerMichael Armbrust <michael@databricks.com>2015-08-24 18:10:51 -0700
commit2bf338c626e9d97ccc033cfadae8b36a82c66fd1 (patch)
tree15051c6ca3378df85dfec0172ce981bc81296870 /R/create-docs.sh
parentd7b4c095271c36fcc7f9ded267ecf5ec66fac803 (diff)
downloadspark-2bf338c626e9d97ccc033cfadae8b36a82c66fd1.tar.gz
spark-2bf338c626e9d97ccc033cfadae8b36a82c66fd1.tar.bz2
spark-2bf338c626e9d97ccc033cfadae8b36a82c66fd1.zip
[SPARK-10165] [SQL] Await child resolution in ResolveFunctions
Currently, we eagerly attempt to resolve functions, even before their children are resolved. However, this is not valid in cases where we need to know the types of the input arguments (i.e. when resolving Hive UDFs). As a fix, this PR delays function resolution until the functions children are resolved. This change also necessitates a change to the way we resolve aggregate expressions that are not in aggregate operators (e.g., in `HAVING` or `ORDER BY` clauses). Specifically, we can't assume that these misplaced functions will be resolved, allowing us to differentiate aggregate functions from normal functions. To compensate for this change we now attempt to resolve these unresolved expressions in the context of the aggregate operator, before checking to see if any aggregate expressions are present. Author: Michael Armbrust <michael@databricks.com> Closes #8371 from marmbrus/hiveUDFResolution.
Diffstat (limited to 'R/create-docs.sh')
0 files changed, 0 insertions, 0 deletions