[CALCITE-6224] Add LOG2 function (enabled in Mysql, Spark library)

[caicancai]

https://issues.apache.org/jira/browse/CALCITE-6224

[caicancai]

Regarding the case where the parameter is 0, it will be fixed in another jira
discussion: https://issues.apache.org/jira/browse/CALCITE-6259

[caicancai]

@mihaibudiu @tanclary I added a function to log2 inside Sqlfunctions. I am very sorry that I have not thought of a better solution, if you have, please let me know, I would appreciate it

[caicancai]

https://issues.apache.org/jira/browse/CALCITE-6277

[caicancai]

@tanclary Thank you very much, let's wait for the cli

[tanclary]

I think when you get a review, you should try to make sure you didn't make the same mistakes in other places in the PR. If you fix them all at once it will save you and the reviewer time. Especially when your reviewers are in different time zones, it will help reduce the time it takes to merge the commit.

[caicancai]

I think when you get a review, you should try to make sure you didn't make the same mistakes in other places in the PR. If you fix them all at once it will save you and the reviewer time. Especially when your reviewers are in different time zones, it will help reduce the time it takes to merge the commit.

Maybe what you said makes sense, but the commits that were merged before were written in a similar way. I learned from their writing methods. I don't understand why the previous PR can be merged if I modified it. I don't mean any harm, I just don't understand

[tanclary]

I think when you get a review, you should try to make sure you didn't make the same mistakes in other places in the PR. If you fix them all at once it will save you and the reviewer time. Especially when your reviewers are in different time zones, it will help reduce the time it takes to merge the commit.

Maybe what you said makes sense, but the commits that were merged before were written in a similar way. I learned from their writing methods. I don't understand why the previous PR can be merged if I modified it. I don't mean any harm, I just don't understand

I mean that I've noticed you make the same mistakes multiple times, even after they have been pointed out by a reviewer. You can avoid this by checking over the PR and making sure you fix all instances of a mistake so it saves everyone time. Does that make sense?

[caicancai]

I think when you get a review, you should try to make sure you didn't make the same mistakes in other places in the PR. If you fix them all at once it will save you and the reviewer time. Especially when your reviewers are in different time zones, it will help reduce the time it takes to merge the commit.

Maybe what you said makes sense, but the commits that were merged before were written in a similar way. I learned from their writing methods. I don't understand why the previous PR can be merged if I modified it. I don't mean any harm, I just don't understand

I mean that I've noticed you make the same mistakes multiple times, even after they have been pointed out by a reviewer. You can avoid this by checking over the PR and making sure you fix all instances of a mistake so it saves everyone time. Does that make sense?

My question, sorry

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud