Improves aggregates over decimal translation for PostgreSQL #411
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.
Since Npgsql library does not provide ways to read full range of PostgreSQL decimals but reads only the values that fit to .NET decimals, we have to change cast result type to be compatible with .NET, which may cause some issues later but there is no other suitable option at the moment which would make sense. Options recommended in some official answers don't fit and ridiculous, and the client library maintainers don't see this inability to read whole spectrum of supported values as bug/issue/design flaw which should be fixed/improved.
As a try to somehow predict possible precision and scale of result type, a guessing algorithm introduced which, in case of aggregate over decimal expression, visits the expression and gathers precision and scale of the fields used in the expression and then, and if it is possible, computes scale and precision based on gathered data. In case of complex expressions, containing other numeric types, the algorithm assigns some predefined precisions and scales for them for better result parameters estimation, it doesn't take into account mathematical operations though, which would add complexity and make expression visiting slower.
Later, on translation of providers and if aggregate expression is not a single column but complex expression, another assumption made. Maximal .NET precision (28) is used for database type precision and scale defines with a bit bigger resolution to attempt to not lose result of AVG and SUM operation. What's left from increasing scale goes basically to floor part of result value.
For aggregates over simple column no cast applied, precision and scale will be this implicitly declared by the column settings on server side.