Correct a defect in count subquery select clause calculation #136
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.
Fixes 2 issues:
Referenced column names from the HAVING clause were inappropriately
attributed to the primary "me." table alias in all cases, These now
maintain appropriate provenance.
The same column being used as part of both the GROUP BY and the
HAVING clauses ended up appearing multiple times in the reconstructed
SELECT statement, causing confusion in the SQL engine (resulting in
exceptions). The HAVING clause components are now checked against all
assembled SELECT members instead of just other HAVING members when
performing deduplication.
Adds a combined unit test covering both use cases, which failed on the
prior version of the method.
Minor fixes:
Memoized the primary table alias prefix, since this was used in multiple
string interpolations throughout the _count_subq_rs method (in one case,
within a regex without explicit qualification or meta quoting; this has
been turned into a safer (and faster) index call instead).