I don’t think that SqlFunctions has a problem. Using my IDE I can navigate to any of the functions using a few keystrokes. Because I never needed to scroll through the file, I never noticed how many lines it had.
Occasionally people add methods because they think that every SQL function needs a corresponding method. That’s not true. SqlFunctions is a place to put whatever code is necessary for generation. If a SQL function can be implemented by rewriting to simpler SQL functions, or can reuse existing methods, developers should take that route. Finally, a reminder that SqlFunctions is not a public API, or utility code. It is just a runtime library for code generation (analogous to libc). Julian > On Jan 30, 2024, at 07:02, Cancai Cai <caic68...@gmail.com> wrote: > > Hi Forward Xu, > I think this is a good idea. This can not only improve the readability and > maintainability of the code, but it may also be helpful for new developers > to learn. However, how to migrate safely is a big problem, because we > cannot influence User upgrade Maybe we should start with a String Function > > Best, > Cancai Cai > > Forward Xu <forwardxu...@gmail.com> 于2024年1月30日周二 14:06写道： > >> hi Tanner, >> Thank you very much for your reply. >> In the ISO/IEC SQL standard, scalar functions can be classified into the >> following types: >> 1. String functions: Functions for manipulating string data, such as >> CONCAT(), SUBSTRING(). >> 2. Numeric functions: Functions for working with numeric data, such as >> ABS(), ROUND(). >> 3. Date and time functions: Functions for manipulating date and time data, >> such as DATEADD(), DATEDIFF(). >> 4. System functions: Functions providing information about the database >> environment and other system-related details, such as CURRENT_DATE, >> CURRENT_USER. >> >> Best, >> ForwardXu >> >> Tanner Clary <tannercl...@google.com.invalid> 于2024年1月30日周二 12:21写道： >> >>> I don't think it's a bad idea but I'm also not sure whether it's worth >> the >>> time and effort of deciding what functions should be grouped together, >> etc. >>> Seeing as how methods in that class are mostly (always?) called via >>> reflection, I think having them in one place is helpful in ensuring >>> consistent code style/patterns. Test classes in Calcite, for instance, >> vary >>> in thoroughness, documentation, formatting, etc, but individual tests in >>> the same class rarely vary from one another. That's just from a >>> maintenance/consistency perspective, if there's some performance issues >> or >>> otherwise that I'm neglecting then maybe it is worth the attention. >>> >>> Tanner >>> >>> On Mon, Jan 29, 2024 at 8:02 PM Forward Xu <forwardxu...@gmail.com> >> wrote: >>> >>>> hi, >>>> I noticed that the code file of the SqlFunctions.java class is getting >>>> larger and larger and the functions are increasing. I think some >>> functions >>>> can be broken down into different function classes to slim down >>>> SqlFunctions. For example: json functions use JsonFunctions, and only >>>> SqlFunctions retain Function name reference. >>>> >>>> What do you think? >>>> >>>> Best, >>>> ForwardXu >>>> >>> >>
