More precise Integer type inference, and fix #51236#53003
More precise Integer type inference, and fix #51236#53003Avogar merged 19 commits intoClickHouse:masterfrom
Conversation
|
This is an automated comment for commit 5c2fd38 with description of existing statuses. It's updated for the latest CI running
|
if UInt64(possible: Int64), UInt64(possible: Int64) = UInt64, UInt64 if Int64(possible: UInt32), Int64(possible: UInt32) = Int64, Int64
…if it is causing the zk validation failure issue.
ca71c39 to
12d262e
Compare
…the feature of automatically recognizing UInt64 as Int64.
|
@Avogar I have completed all the modifications, and I believe this pull request is now ready for review. I would greatly appreciate it if you could take a look when you have some free time. |
|
Sure, I will look at it today |
|
Thank you for the review and suggestions! I will make the necessary changes promptly. |
6cd6c23 to
5719505
Compare
22fe673 to
74485f3
Compare
…ating modifications to DataType.
|
Sorry for long review, I was on vacation. |
src/DataTypes/FieldToDataType.cpp
Outdated
| DataTypes element_types; | ||
| element_types.reserve(x.size()); | ||
|
|
||
| auto checkIfConversionSigned = [&](bool& has_signed_int, bool& has_uint64, bool& uint64_could_opposite, |
There was a problem hiding this comment.
I see we have 2 identical lambdas here and during Map processing. Let's move this code to a separate function in anonimous namespace in this cpp file.
There was a problem hiding this comment.
And also the logic is the same here and later during Map processing. Maybe we can extract all this logic to a separate function?
Like
void convertUInt64ToInt64IfPossible(DataTypes & data_types);So the code here will look like this:
...
for (const Field & elem : x)
element_types.emplace_back(applyVisitor(*this, elem));
convertUInt64ToInt64IfPossible(element_types);
...It will be much better for future readers
There was a problem hiding this comment.
OK, I'll handle it.
No worries, I hope you had a great vacation! |
Avogar
left a comment
There was a problem hiding this comment.
Looks good, thanks for the contribution!
|
I just realized that this approach with changes only in I think we can get back to the approach with changes in |
|
No worries, I will do such changes by myself, so, no need to do anything, I just wanted you to know. |
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
More precise Integer type inference, fix #51236
Documentation entry for user-facing changes
FieldToDataType<on_error>::operator() (const Array & x)andFieldToDataType<on_error>::operator() (const Map & map)will be able to recognize whether an UInt64 is unsigned, signed, or both, which means that an Int will have multiple possible types. This will make the getLeastSupertype function more accurate.Example :
select [-4741124612489978151, -3236599669630092879, 5607475129431807682]
'-4741124612489978151' is Int64, '-3236599669630092879' is Int64, '5607475129431807682' is UInt64 or Int64.
So, their least supertype is Int64