-
Notifications
You must be signed in to change notification settings - Fork 550
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
Ensure validation of partitioned by columns in the insert from subquery #14317
Conversation
bc0832d
to
8534da1
Compare
return NestableCollectExpression.constant(val); | ||
return NestableCollectExpression.constant(ref.valueType().implicitCast(val)); | ||
} else { |
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.
Otherwise scalar function representing CHECK fails with "left and right must have the same type for comparison"
e4a4337
to
4df7554
Compare
50ffe2d
to
1b6a41d
Compare
|
||
// Partitioned by columns are not included into target columns in the insert-from-subquery code path. | ||
// Ensure that column constraints are checked for partitioned columns as well. | ||
for (int i = 0; i < table.partitionedByColumns().size(); i++) { |
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.
Shouldn't this be surrounded by if (partitionName != null)
?
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.
Isn't the partition already created at this point? If so, bailing out here will leave an invalid partition behind. I think we are forced to do such checks on partition creation instead.
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.
Good catch, thanks! I added an assertion to the test about non-existing index and it fails now. Will move the check to the earlier phase.
Maybe worth double checking that the update integration of the indexer plays well with this too? |
1b6a41d
to
d1deb2e
Compare
316c6b7
to
39aca9e
Compare
39aca9e
to
b5dc89e
Compare
bff82cd
to
2315cc5
Compare
2315cc5
to
4882be4
Compare
3442f67
to
2acdc63
Compare
I tried to replicate problematic queries on UPDATE code path via
|
0990692
to
4428217
Compare
Relates to #14304 (fixes some other bugs as well)
Supersedes #14305