Starrocks v3.1.0 decimal 类型where 查询结果不正确

我看这两个pr 的修改可能跟这个问题有关系。

[BugFix] Fix decimalv2 to string different as BE
[BugFix] unify cast decimal to string between FE and BE

是的，怀疑是这个，后来修复了

我看是 2023.9.4 和 2023.9.6 (昨天) 提交了到branch-3.1 的，我等一等新的 小版本 v3.1.3 发布后，然后我升级验证一下

刚升级到 v3.1.3-384ba23，目前看起来问题没有修复，下面是最新的测试结果

select count(distinct id) from sr_tmp_test where v1=‘12.345’;
– result: 0
select count(distinct id) from sr_tmp_test where v1=‘12.3450’;
– result: 2
select count(distinct id) from sr_tmp_test where v1=12.345;
– result: 2
select count(distinct id) from sr_tmp_test where v1=12.3450;
– result: 2

我用你这个测试表和数据试了一下，还真是。。目前是3.1.2-4f3a2ee版本。
插入表后是

select count(distinct id) from sr_tmp_test where v1=‘12.345’;
– result: 0
select count(distinct id) from sr_tmp_test where v1=‘12.3450’;
– result: 2
这两个结果跟表展示的确实有差异。。看来还挺严重，我还准备把生产环境迁移数据使用呢

@trueeyu 大佬，这个你确认一下是不是bug，目前看v3.1.3 还是有问题。

我测试了下，确实有问题，我们查下

尽量不要使用隐式类型转换，这个规则，我们内部再整理下。这个应该是Const类型的隐式类型转换规则，不同地方处理不一致导致的。

3.1的规则是：const能无损转decimal的转decimal，不能转的时候，大家都转varchar比较。但是判断这个Const是否能无损转Decimal的逻辑，我们内部还需要讨论下，当前是判断12.3450不能无损转，所以就都转成Varchar来比了，而const类型转成的varchar,后面少了个0,列Decimal类型转varchar后，后面有0

我们现在先在业务层面上根据字段类型做转换。 后面 v3.1.x 的后续的小版本，会修复这个问题么？ @trueeyu

这个应该短期不会修复，可能后面会已新的转换规则为准，不然会出现一些其它奇怪的问题，最好是尽量避免使用隐式类型转换。后面也有可能会加个SqlMode来选择使用哪种方式，这个内部还有争论。

这个新的PR 是解决 decimal 对比string 的问题的解决方案么？ https://github.com/StarRocks/starrocks/pull/34208

是的，是解决这个问题的

要兼容的话，需要把这个开关，set成false。可以兼容以前的

我们期望和 3.0.x 版本的行为保持一致就行，cbo_decimal_cast_string_strict 这个是配置是设为 true 还是false ?

设置成 false 可以和以前一样

升级了 v3.1.5 设置 set cbo_decimal_cast_string_strict = false; 让后执行SQL 目前结果复合预期，已经和3.0 的行为保持一致。

请问一下, 可不可以支持 cast(decimal_field as varchar) 在非严格模式下 123.000转为123
set cbo_decimal_cast_string_strict = false;

表结构和SQL发下？

create table test_decimal(a decimal(38,8));
insert into test_decimal values(123.000)
select cast(a as varchar)
– 123.00000000