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
Standardize handling of impure functions #10445
Comments
@MaterializeInc/dataflow-optimization any qualms with the proposal here? |
Not in theory. I will need to dig deeper and scope out what work needs to be done so we can have all checks in place. To recap, what you are proposing is to allow impure functions in |
Precisely! It'll look quite similar to I'm not entirely certain, but it's possible that this all gets transformed away before the optimizer ever sees it. |
Marking this with |
This SGTM. |
Feature request
Today in Materialize we allow some impure functions: i.e., functions whose results are not wholly determined by their inputs.
Most impure functions are easy to spot because they take no arguments. Common examples include:
now()
current_user()
current_database()
We're fairly inconsistent in what we allow you to do with these functions. You can always use them outside of a view:
You can use
current_user()
andcurrent_database()
in a view:But using
now()
in a view is banned:This doesn't make a whole lot of sense. Look what happens if you query
weird
after a restart:It's changed!
I propose that instead we allow all impure functions in views, and instead reject creating indexes on any view that references an impure function, whether directly or via another view. This would fix:
now()
pg_catalog
views, which want to filter based oncurrent_database()
and perhapscurrent_user()
(sql:pg_catalog
views do not limit to the current database #10391)current_user()
changing tomz_system
after a restartThe text was updated successfully, but these errors were encountered: