[
https://issues.apache.org/jira/browse/ARROW-16811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552993#comment-17552993
]
Yaron Gvili commented on ARROW-16811:
-------------------------------------
You are referring to this post. This limited-bind is not ideal, though it can
be useful as an intermediate solution in places in the code that cannot be
easily changed to a work with a non-default ExecContext. I imagine this could
be the case in some user-facing APIs that currently do not take an ExecContext,
and eventually defaults to the global function registry (perhaps examples exist
in the dataset package?). In such cases, there are two options to consider:
either break user code to force it to provide an ExecContext, or keep user-code
intact but fail on runtime when an expression gets bound in a non-safe way. The
latter one is what I wanted to draw attention to.
> [C++] Remove default exec context from Expression::Bind
> -------------------------------------------------------
>
> Key: ARROW-16811
> URL: https://issues.apache.org/jira/browse/ARROW-16811
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Reporter: Weston Pace
> Assignee: Weston Pace
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This came up in https://github.com/apache/arrow/pull/13355.
> It is maybe not very intuitive that Expression::Bind would require an
> ExecContext and so we never provided one. However, when binding expressions
> we need to lookup kernels, and that requires a function registry. Defaulting
> to default_exec_context is something that should be done at a higher level
> and so we should not allow ExecContext to be omitted when calling Bind.
> Furthermore, [~rtpsw] has suggested that we might want to split
> Expression::Bind into two variants. One which requires an ExecContext and
> one which does not (but fails if it encounters a "call").
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
