[CALCITE-6259] The implementation of the Log library operator does not match the actual dialect behavior

[caicancai]

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

[caicancai]

It looks like there is a class loading conflict. Can anyone help me answer this question, I would be very grateful

[caicancai]

@tanclary It seems like I don't have a good way to solve this problem. Can you give me some advice?

[tanclary]

@tanclary It seems like I don't have a good way to solve this problem. Can you give me some advice?

Can you be more specific? What problem?

[caicancai]

Can you be more specific? What problem?

Thank you for your reply. You can find that I defined ReturnTypes.DOUBLE_FORCE_NULLABLE in LOG10_MS. The purpose is to make LOG10_MS return null when log10(0). However, during my debugging process, I found that the ReturnTypes.DOUBLE_FORCE_NULLABLE I defined did not take effect.

@LibraryOperator(libraries = {MYSQL, SPARK})
  public static final SqlFunction LOG10_MS =
      ((SqlBasicFunction) LOG10).withKind(SqlKind.LOG10_MS)
          .withReturnTypeInference(ReturnTypes.DOUBLE_FORCE_NULLABLE);

Regarding the ReturnType processing of LOG10_MS, it still follows the ReturnType logic of LOG10 in SqlStdOperatorTable

public static final SqlFunction LOG10 =
      SqlBasicFunction.create("LOG10",
          ReturnTypes.DOUBLE_NULLABLE,
          OperandTypes.NUMERIC,
          SqlFunctionCategory.NUMERIC);

Can you understand what I mean?

I feel that the ReturnTypes.DOUBLE_FORCE_NULLABLE of LOG10_MS I defined must be overwritten. Yes, I must have overlooked something

[sonarqubecloud[bot]]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

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

See analysis details on SonarCloud

[caicancai]

@tanclary I feel that I cannot change SqlStdOperatorTable, which will affect some other tests (I tried)

[jduo]

@tanclary I feel that I cannot change SqlStdOperatorTable, which will affect some other tests (I tried)

I raised a similar question on the mailing list and didn't hear back. See: https://lists.apache.org/thread/dloo5q43k6b739gqmg1qf2hht3wzvt0t

I think we need to edit the parser so that when it encounters the LOG function, we call a method to look up the SqlOperator based on the SqlConformance. Similar to what looks to have been suggested for Floor/Ceil. @tanclary @julianhyde perhaps you know?

[julianhyde]

No, the parser should not be making decisions about semantics. The validator (assisted by the operator table) should be doing that.

[caicancai]

No, the parser should not be making decisions about semantics. The validator (assisted by the operator table) should be doing that.

Hi，thank you for your reply. I would like to ask if there are any previous cases similar to Jira that I can learn from. I don’t have a good idea at the moment. I should try Benchao’s idea https://lists.apache.org/[email protected] , but I’m not sure if I can complete it.

[caicancai]

@tanclary In addition, I have to explain that currently calcite's log10(0) returns -Infinity, but many databases I tested returned NULL or errors. I am not sure whether I should modify the underlying implementation of the log function (Sqlfunctions.log) , or create a new function

[caicancai]

I created two corresponding subtasks because the PR code changes may be large, and I am not sure about the ln and log10 functions, so I will adapt the log function first. Thank you for your reviews and suggestions.

I'm sorry about that