Skip to content
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

feat: add skip_nulls option to scalar aggregate functions #388

Closed
wants to merge 3 commits into from

Conversation

thisisnic
Copy link
Contributor

This PR adds a skip_nulls option to each of the scalar aggregate functions, with a default value of TRUE (which would just replicate existing behaviour) for all of these functions except for quantile() which had the previous behaviour of returning NULL if any input values are NULL.

Although some backends remove NULL values by default in computations, others allow specifying this option to return an NULL value if any of the input values are NULL.

Now I've done this, I'm wondering if this is something relevant to the NULLABILITY HANDLING field, but if I'm completely honest I still don't understand it after reading the docs (that said, I'm happy to submit another PR updating the docs for that section if someone reviewing this explains it to me!) I don't think that's relevant here, though I'm not sure.

@CLAassistant
Copy link

CLAassistant commented Nov 25, 2022

CLA assistant check
All committers have signed the CLA.

@@ -756,6 +756,8 @@ aggregate_functions:
options:
overflow:
values: [ SILENT, SATURATE, ERROR ]
skip_nulls:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we should add this property to the aggregate function invocation as opposed to every aggregate function. It feels kind of like aggregate input sorting or some other function-impl independent concept. Thoughts @westonpace @gforsyth ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that if we're specifying an option for every function definition that we should move it up to the invocation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense, will close this PR and have opened #401 instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants