Figured I'd throw this in here (and for postgres) while I'm at it. I'm taking an educated guess at the correct order here; my brain is still spinning from trying to follow SQLite's logic.

Ideally we should use the ordering from the db/dialect. Postgres has this algorithm: https://www.postgresql.org/docs/current/typeconv-union-case.html while ms-sql (not support at the moment) provides this nice list: https://learn.microsoft.com/en-us/sql/t-sql/data-types/data-type-precedence-transact-sql?view=sql-server-ver16

OK I'll take a look

I was double checking the type order for the MAX/MIN functions when I realized that in essentially all dialects except SQLite, MAX/MIN only allow a single argument, and for multiple arguments you should use GREATEST, LEAST.

This would allow simply taking the type from the expression list, but SqlDelight allows passing multiple arguments to MAX/MIN. I have a pretty simple changeset to not allow that, but I'm not sure if SqlDelight is looking to validate function usage. Some tests would have to be updated to only include SQLite when using MAX/MIN, and new tests would have to be added to exclude SQLite and test GREATEST/LEAST.

I don't want to do too much more work on that without a clear direction, so @hfhbd what do you think?

Put up the PoC here

Well, on the one hand I like "hardening" compiling sql code, on the other hand having this check code in the grammar is annoying with the current function resolver code in the dialect. Limiting the parameters in the grammar is way complex. I would simple put this logic in the function resolver and use exprList.single() or similar. The drawback is missing grammar support.

Limiting the parameters in the grammar is way complex

My PoC seemed pretty simple, am I missing something? I'm even considering have a mixin per dialect that can handle function validation at the grammar level for all functions (maybe with an ANSI base so it doesn't have to be repeated everywhere), and it would be pretty straightforward. That way there wouldn't need to be a mixin per function.

The drawback is missing grammar support

Which I think would be cool to have, and I'm happy to work on it. The only thing stopping me is the question of whether this falls in SqlDelght's domain. Nothing would technically stop working in SqlDelight without it.

I would put the mixin in sql-psi, if we want it at all (+ Function1Param, Function2Param, etc). But the annoying things is to create a grammar rule for each possible function and to add the function + its return type in function resolver (or in another mixin).

My idea was to override function_expr in each dialect using the same definition as sql-psi (function_expr ::= function_name LP [ [ DISTINCT ] expr ( ( COMMA | FROM | FOR | SEPARATOR ) expr ) * | MULTIPLY ] RP) and add a mixin.

Then each dialect can define how to handle each function in the mixin itself, by keying off of the name of the function. It could delegate to a "common" class that validates functions following ANSI, and have custom handling for things that are different in the specific dialect.

I'll push a commit to my PoC showing this

🙈 OK somehow I was missing what the existing FunctionExprMixin was doing. I updated the PoC to use that.