Error when encountering an unsupported aggregate function#1020
Open
sgrif wants to merge 1 commit into
Open
Conversation
This comment has been minimized.
This comment has been minimized.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
levkk
approved these changes
May 28, 2026
levkk
reviewed
May 28, 2026
sgrif
force-pushed
the
sg-error-on-unsupported-aggregates
branch
from
fb4cfe1 to
ed257bc
Compare
sgrif
force-pushed
the
sg-error-on-unsupported-aggregates
branch
from
ed257bc to
a4687cb
Compare
Contributor
Author
|
Decided to move forward with this without handling direct-to-shard |
When handling aggregate functions in cross-shard queries, we can only return a correct result for functions that we have explicit support for. No matter what the aggregate function is doing, we need to know how to combine the results from the separate shards. Prior to this change, we would just silently do the wrong thing, treating this as any other non-aggregate expression and just returning a union of the rows from each query. We now explicitly check if an aggregate function with that name exists and error if we don't recognize it. This is future proofed against new functions in later postgres versions, as well as user defined aggregates (which we can likely never support). This will produce a false positive if a function exists and is defined as aggregate for some argument types but not others. But frankly anyone doing that is asking for trouble. In theory we could potentially not error on direct-to-shard queries, but ultimately handling that proved to be a massive rabbit hole. It's something I'd like to do in the future after more refactoring, but for the time being it seems reasonable to assume that if `SELECT mysum(...)` fails, `SELECT mysum(...) WHERE shardkey = 1` would also fail
sgrif
force-pushed
the
sg-error-on-unsupported-aggregates
branch
from
c9484f1 to
40c5c84
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
When handling aggregate functions in cross-shard queries, we can only return a correct result for functions that we have explicit support for. No matter what the aggregate function is doing, we need to know how to combine the results from the separate shards.
Prior to this change, we would just silently do the wrong thing, treating this as any other non-aggregate expression and just returning a union of the rows from each query. We now explicitly check if an aggregate function with that name exists and error if we don't recognize it.
This is future proofed against new functions in later postgres versions, as well as user defined aggregates (which we can likely never support). This will produce a false positive if a function exists and is defined as aggregate for some argument types but not others. But frankly anyone doing that is asking for trouble.
This logic is objectively in the wrong place. What we are doing here is validation, not parsing. However as I'm familiarizing myself with these code paths and preparing a larger rearchitecture, I'm slowly hammering things into a shape that's easier to move around. I do not intend on leaving this logic here long term.