Is your feature request related to a problem?
I discovered that in MySQL some functions' return type depends on arguments' values (not on their types❗)
For example, DATE_ADD function returns
DATETIME when arguments are TIME and date or complex INTERVAL
DATETIME when arguments are DATE and time or complex INTERVAL
TIME when arguments are TIME and time INTERVAL
DATE when arguments are DATE and date INTERVAL
- ...
So function had following signature:
(DATE, INTERVAL) -> DATE
(DATE, INTERVAL) -> DATETIME
(TIME, INTERVAL) -> TIME
(TIME, INTERVAL) -> DATETIME
...
Which is extremely ambiguous for Resolver. It picked first matching signature (last in the list) and used it for further resolving.
In the given example (see pic), a signature which returns DATE was resolved, but actual function execution returned DATETIME.

What solution would you like?
Introduce 3 new INTERVAL-like types instead of existing INTERVAL (ExprIntervalValue):
DATE_INTERVAL which operates with date terms, like days, months and years
TIME_INTERVAL which operates with time terms, e.g. hours, minutes and so on
DATETIME_INTERVAL which all datetime terms
- These types shouldn't be visible for user to avoid confusion. Syntax shouldn't be changed.
- These types should support more than one term, e.g. 'x hours y seconds' and even 'x years y minutes' for
DATETIME_INTERVAL. This feature should implement complex interval expressions.
- This feature should contain update for
DATE_ADD function (and its siblings: ADDDATE, SUBDATE, DATE_SUB) as a use case:
(DATE, DATE_INTERVAL) -> DATE
(DATE, TIME_INTERVAL) -> DATETIME
(DATE, DATETIME_INTERVAL) -> DATETIME
(TIME, TIME_INTERVAL) -> TIME
(TIME, DATE_INTERVAL) -> DATETIME
(TIME, DATETIME_INTERVAL) -> DATETIME
What alternatives have you considered?
N/A
Do you have any additional context?
#855
Is your feature request related to a problem?
I discovered that in MySQL some functions' return type depends on arguments' values (not on their types❗)
For example,
DATE_ADDfunction returnsDATETIMEwhen arguments areTIMEand date or complexINTERVALDATETIMEwhen arguments areDATEand time or complexINTERVALTIMEwhen arguments areTIMEand timeINTERVALDATEwhen arguments areDATEand dateINTERVALSo function had following signature:
Which is extremely ambiguous for
Resolver. It picked first matching signature (last in the list) and used it for further resolving.In the given example (see pic), a signature which returns
DATEwas resolved, but actual function execution returnedDATETIME.What solution would you like?
Introduce 3 new
INTERVAL-like types instead of existingINTERVAL(ExprIntervalValue):DATE_INTERVALwhich operates with date terms, like days, months and yearsTIME_INTERVALwhich operates with time terms, e.g. hours, minutes and so onDATETIME_INTERVALwhich all datetime termsDATETIME_INTERVAL. This feature should implement complex interval expressions.DATE_ADDfunction (and its siblings:ADDDATE,SUBDATE,DATE_SUB) as a use case:What alternatives have you considered?
N/A
Do you have any additional context?
#855