Thomas B

> * Maybe just `define_sql_function!` instead Love that name! 😃 > Move the free register_ function as associated functions onto the struct. Not sure what struct you're thinking of -...

> I'm thinking about the struct generated by the macro Somewhat raw thoughts: I'm not sure that works through the type alias that remaps the type arguments through an AsExpression......

TBH I think I am reasonably happy with the extra module. It's not particularly elegant but I feel like it's probably the most programmatically appropriate representation, and we don't necessarily...

> `{function_name}_implementation` I'm not super fond of that name either but `{function_name}_internals` doesn't feel better indeed. 😅 Overall both convey that this is where stuff is implemented but AFAICT we...

closing in favor of #3783

> I think this is now mostly ready for review This is on my to-do list, I need to find the time to have a look at it - not...

Sorry for the huge delay 😔 So this approach of updating the type aliases names to their PascalCase names has the downsides that: - As you pointed out, there are...

> Maybe it's an option to just add a #[auto_type_compatible] annotation to the existing macro and emit a deprecated warning for all calls that do not have that attribute? I...

@weiznich this might be an issue with the "type alias at the same path as function" approach (might require breaking change) so I think it's a blocker for the release....

> `#[auto_type]` can then internally use that dsl module by default if it did then custom functions couldn't be referred directly anymore. That's notably why it uses "always same path...