-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
External Table Primary key support #7755
Conversation
# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed this PR and it looks good to me. It'd be good to get some community feedback in case something escaped my eye.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really nice to me -- thank you @mustafasrepo
I think we should
- add a round trip test for the new protobuf code,
- Error if unsupported constraints are used
but otherwise, it looks good to go to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you 🙏
Which issue does this PR close?
Closes #7154.
Thanks @parkma99 for the initial work in #7161
Rationale for this change
With the changes in this PR, we can use use primary key information in the external tables also.
What changes are included in this PR?
Are these changes tested?
Yes new tests are added to show that, primary key information is used during planning. With these changes query below can run
even if column
b
is not among the group by expressions, when it is known that columnc
is primary key. In this case we are sure that, for each uniquec
value, there will be correspondingb
value (b
is functionally dependent on thec
). Hence, above query can run successfully.Are there any user-facing changes?