-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Regression: count(*) does not work unless using default expression planners #15114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
|
I'm not sure which one is better, adding an |
The difference is that if you add |
I think adding |
Then we can add it to |
take |
BTW I think we should consider fixing this in a 46.0.0 release. |
Uh oh!
There was an error while loading. Please reload this page.
Previously, the count wildcard is expanded by the CountWildCard analyzer rule which however was removed in the latest release 46.0. And the functionality is now moved to the ExprPlanner for planning aggregate functions, see #14689.
This functionality assumes users could get expression planners from the ContextProvider. See:
datafusion/datafusion/sql/src/expr/function.rs
Lines 374 to 379 in dfaede0
It's ok for the DataFusion native context provider
SessionContextProvider
since it's able to retrieve expression planners from the SessionState. See:datafusion/datafusion/core/src/execution/session_state.rs
Lines 1619 to 1627 in dfaede0
Unfortunately, user defined ContextProvider is unable to get expression planners from the SessionState, since the
expr_planners
field is not exposed.As a result, users who wish to utilize the default expression planners must import the
FunctionRegistry
trait, which provides anexpr_planners
method, and notably, SessionState implements this trait.To address this issue, I propose adding a method to SessionState that returns a reference of the registered expression planners. This would provide a more straightforward and consistent way for user-defined ContextProvider implementations to access these planners without requiring importing the additional
FunctionRegistry
trait.The text was updated successfully, but these errors were encountered: