sjyango commented on issue #28387: URL: https://github.com/apache/doris/issues/28387#issuecomment-1855455132
> > > This behavior meets our expectation. The column for ipv4stringtonum or ipv4stringtonumordefault is set to be **always not nullable**, so that we can have a precheck for the Null situation. > > > If you want to not check for this, you can use **ipv4stringtonumornull** or use the **nvl** function to deal with your column first. > > > > > > But function ipv4stringtonumordefault 's behavior is different from what is defined in ClickHouse > > In Clickhouse, are these ipv4 stringtonum functions: ipv4stringtonum(ordefault, ornull) all set to nullable column input? I think so. In my opinion, ipv4stringtonum (ordefault, ornull) needs to support handling nullable columns, and then take different actions based on different values in the function logic. For example, when encountering NULL or invalid format ip strings, ipv4stringtonum will throw an exception, ipv4stringtonumordefault will return 0, and ipv4stringtonumornull will return NULL. I analyzed your code and found that you defined Ipv4StringToNumOrDefault as AlwaysNotNullable in fe, but in be's get_return_type_impl function, ambiguity occurred in the implementation of the function. If IPStringToNumExceptionMode is set to Default, the return type may be nullable, making it impossible to call Ipv4StringToNumOrDefault to handle columns with null values <img width="1167" alt="image" src="https://github.com/apache/doris/assets/114391101/f37e4b2e-c953-4398-b558-1b1b013eee31"> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
