-
Notifications
You must be signed in to change notification settings - Fork 25
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
support join select #29
Conversation
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## master #29 +/- ##
==========================================
- Coverage 77.87% 76.22% -1.65%
==========================================
Files 7 7
Lines 931 959 +28
==========================================
+ Hits 725 731 +6
- Misses 155 165 +10
- Partials 51 63 +12
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
The high level idea is we need to keep track of all the aliases definitions when parsing the queries, so I think your design is on the right track 👍 |
Latest commit introduced |
@houqp I think this is ready |
Thanks @valichek for the feature! |
Please, review the changes, further directions required.
At the point this change will fix error from #26
But another error comes out
Following changes done in own commit being negotiable.
It looks like the only way to proceed is to pass tables used from top level here and join with ones parsed in
validateSelectStmt(...)
The first thing that comes to my mind is to add top-level used tables to
VetContext
It will go down through all the select statements in hierarchy. In order this to work properly used tables may be collected in
ParsedResult
.Not much of test cases available in the project so maybe someone could point to the possible pitfalls of such decision.