I think it is difficult and impossible to make calcite function results completely consistent with other SQL systems. In practice, when calculations are pushed down to different data source adapters for execution, there is no guarantee that the final results will be completely consistent in calcite.
I think, for the built-in functions defined in `SqlStdOperatorTable`, we can choose to follow one of the definitive SQL systems, such as Oracle. For the engine-related extension functions in `SqlLibraryOperators`, we can follow the behavior related to the specific engine. If an already defined function behaves inconsistently with the new engine, we can add a new Function to the definition, such as the `CONCAT` function. At the same time, I agree it is a great suggestion to add execution tests of different engines in Quidem, which is very effective in verifying the engine execution behavior. Cancai Cai <caic68...@gmail.com> 于2024年2月26日周一 09:59写道： > Thank you very much to the calcite community for raising these questions. > This is what I have been doubting. I am very sorry that this doubt has been > discussed for so long. > > Maybe we also need to consider another issue, that is, the database version > issue. Versions like mysql and postgres are very stable, but components > like spark still seem to have function bugs. exists, then how should we > consider version issues? > > I don't know what I can do. Recently I am sorting out some documents about > the use of some functions of mysql and postgres in calcite. I don't know if > this is helpful. > > Best wishes, > Cancai Cai >
