[CALCITE-6699] Invalid unparse for Varchar in StarRocksDialect#4055
[CALCITE-6699] Invalid unparse for Varchar in StarRocksDialect#4055xiaochen-zhou wants to merge 1 commit intoapache:mainfrom
Conversation
|
xiaochen-zhou
changed the title
| return new SqlDataTypeSpec( | ||
| new SqlBasicTypeNameSpec(SqlTypeName.BIGINT, SqlParserPos.ZERO), | ||
| SqlParserPos.ZERO); | ||
| case VARCHAR: |
There was a problem hiding this comment.
We need to add a unit test.
There was a problem hiding this comment.
what happens to the precision if it is specified?
There was a problem hiding this comment.
+1. The accuracy issue is not considered here.
There was a problem hiding this comment.
test
Sorry for the late reply. I will add it later today.
There was a problem hiding this comment.
what happens to the precision if it is specified?
I initially thought that if precision is not set here, the default precision for varchar might be used. However, I just looked at the code, and it seems that if precision is not set, the default is PRECISION_NOT_SPECIFIED. Could this lead to a loss of precision, or did I not look at the code carefully?
There was a problem hiding this comment.
You can try to follow the startRocks behavior. Does Starrocks support Varchar without setting precision? If so, add test cases to override it. If not, set the default varchar precision to Starrocks' default value. Also, add unit test to cover when Varchar setting precision.
There was a problem hiding this comment.
I tried cast varchar with precision in Starrocks, and it seems that the precision doesn't affect the result and type(If the precision does not exceed 65533).
There was a problem hiding this comment.
I tried cast varchar with precision in Starrocks, and it seems that the precision doesn't affect the result and type(If the precision does not exceed 65533).
Although this is not a common situation, we should still consider it.
There was a problem hiding this comment.
VARCHAR(N) is supposed to truncate to N characters, and then trim the whitespaces from the end of the string.
If the dialect does not support VARCHAR(N) perhaps it should report an error when an attempt is made to use it.
Then you should also add an assertion that the precision is "not specified".
|
This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 90 days if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@calcite.apache.org list. Thank you for your contributions. |
5 participants
https://issues.apache.org/jira/projects/CALCITE/issues/CALCITE-6699