Add support for ordered-set aggregation functions (WITHIN GROUP)
#576
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This means that expressions contained in `ORDER BY` clauses of aggregation functions are now also renamed by `extractAggregateFields`.
This commit adds support for ordered-set aggregation functions such as `mode()` which use the `WITHIN GROUP (ORDER BY _)` syntax. However, it doesn't actually expose any public facing API for this, basically because I don't know yet what that API should be for Opaleye. There are a lot of subtle restrictions on the kinds of arguments you can pass to the ordered-set aggregation functions (e.g., `percentile_disc()` can take either a constant expression or one of the columns from the query we're aggregating over, but only if it's part of the `GROUP BY` clause) that would be hard to capture in the types that Opaleye currently uses. What this commit does is add just enough internals for me to able to experiment with a limited API in Rel8 for ordered-set aggregation functions that might be subject to change in the future. But I don't want to add something half-baked to Opaleye's public facing API just yet.
shane-circuithub
force-pushed
the
within-group
branch
from
1eea642
to
7f8b018
Compare
|
Yup, all good. Likewise split up a bit and merged separately. Due to the splitting tool all the commits get attributed to me. Sorry about that. I try to credit you on all the commits, e.g. 1367e70. If you feel strongly about this please let me know and I'll see what I can do to fix the tool. |
|
No worries at all, I don't care about the attribution, just happy to have this merged so I can play around with it! Thanks for being so responsive in the last week with all the PRs. |
|
You're welcome. Thanks for the great PRs! |
tomjaguarpaw
added a commit
that referenced
this pull request
Jan 21, 2024
It's redundant because we only need to rebind PrimExprs that came from a lateral subquery. As explained at [1], rather than carefully analysing which PrimExprs came from a lateral subquery we can just rebind everything. A previous commit [2] changed things so that everything mentioned in aggregator order expressions is rebound. Instead we probably should have done what this commit does, that is, added an Unpackspec constraint to aggregate. Fixes #587 This is a simpler approach to resolving the issues discussed at * #585 * #578 This still suffers from the problem described at: #578 (comment) i.e. if we find a way of duplicating field names, such as O.asc (\x -> snd x O..++ snd x) then we can still create crashing queries. The benefit of this comment is that there is a way of generating non-crashing queries! [1] https://github.com/tomjaguarpaw/haskell-opaleye/blob/52a4063188dd617ff91050dc0f2e27fc0570633c/src/Opaleye/Internal/Aggregate.hs#L111-L114 [2] d848317, part of #576
tomjaguarpaw
added a commit
that referenced
this pull request
Jan 26, 2024
It's redundant because we only need to rebind PrimExprs that came from a lateral subquery. As explained at [1], rather than carefully analysing which PrimExprs came from a lateral subquery we can just rebind everything. A previous commit [2] changed things so that everything mentioned in aggregator order expressions is rebound. Instead we probably should have done what this commit does, that is, added an Unpackspec constraint to aggregate. Fixes #587 This is a simpler approach to resolving the issues discussed at * #585 * #578 This still suffers from the problem described at: #578 (comment) i.e. if we find a way of duplicating field names, such as O.asc (\x -> snd x O..++ snd x) then we can still create crashing queries. The benefit of this comment is that there is a way of generating non-crashing queries! [1] https://github.com/tomjaguarpaw/haskell-opaleye/blob/52a4063188dd617ff91050dc0f2e27fc0570633c/src/Opaleye/Internal/Aggregate.hs#L111-L114 [2] d848317, part of #576
tomjaguarpaw
added a commit
that referenced
this pull request
Feb 6, 2024
It's redundant because we only need to rebind PrimExprs that came from a lateral subquery. As explained at [1], rather than carefully analysing which PrimExprs came from a lateral subquery we can just rebind everything. A previous commit [2] changed things so that everything mentioned in aggregator order expressions is rebound. Instead we probably should have done what this commit does, that is, added an Unpackspec constraint to aggregate. Fixes #587 This is a simpler approach to resolving the issues discussed at * #585 * #578 This still suffers from the problem described at: #578 (comment) i.e. if we find a way of duplicating field names, such as O.asc (\x -> snd x O..++ snd x) then we can still create crashing queries. The benefit of this comment is that there is a way of generating non-crashing queries! [1] https://github.com/tomjaguarpaw/haskell-opaleye/blob/52a4063188dd617ff91050dc0f2e27fc0570633c/src/Opaleye/Internal/Aggregate.hs#L111-L114 [2] d848317, part of #576
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds support for ordered-set aggregation functions such as
mode()which use theWITHIN GROUP (ORDER BY _)syntax. However, it doesn't actually expose any public facing API for this, basically because I don't know yet what that API should be for Opaleye. There are a lot of subtle restrictions on the kinds of arguments you can pass to the ordered-set aggregation functions (e.g.,percentile_disc()can take either a constant expression or one of the columns from the query we're aggregating over, but only if it's part of theGROUP BYclause) that would be hard to capture in the types that Opaleye currently uses.What this commit does is add just enough internals for me to able to experiment with a limited API in Rel8 for ordered-set aggregation functions that might be subject to change in the future. But I don't want to add something half-baked to Opaleye's public facing API just yet.