Kiritsgu commented on issue #31567: URL: https://github.com/apache/shardingsphere/issues/31567#issuecomment-2149249069
@TherChenYang Hello, I have reviewed some of the functions mentioned above, such as UPPER(), UCASE(), and UNCOMPRESS(), and found that their corresponding SQLStatements can accurately capture the parameters within the methods, as illustrated below.  I also wrote a simple test case for the SQL query "SELECT UPPER(t.Fname) FROM Ftest t," which passed successfully. If I have misunderstood anything, please feel free to correct me. ` <select sql-case-id="select_upper_function_with_alias">` ` <projections start-index="7" stop-index="20">` ` <expression-projection text="UPPER(t.Fname)" start-index="7" stop-index="20">` ` <expr>` ` <function start-index="7" stop-index="20" text="UPPER(t.Fname)" function-name="UPPER">` ` <parameter>` ` <column start-index="13" stop-index="19" name="Fname" >` ` <owner name="t" start-index="13" stop-index="13" />` ` </column>` ` </parameter>` ` </function>` ` </expr>` ` </expression-projection>` ` </projections>` ` <from>` ` <simple-table name="Ftest" alias="t" start-index="27" stop-index="33" />` ` </from>` ` </select>` Given that the UPPER() function works well, I assume that most other functions should also operate correctly since they all belong to the RegularFunction category. If any changes are needed, they would likely involve a general fix rather than targeting a specific function. That being said, it is puzzling why there are so many similar issues. As for the next steps, could you please guide me? Should I start by identifying functions whose corresponding SQLStatements cannot capture the parameters accurately? -- 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]
