You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Moreover, when I pass a time from the index, it reports an error, but with unexpected error message:
Send a ppl query: source=dates | head 1 | eval d = unix_timestamp(time) | fields d, where time is of type TIME.
It reports an error like below:
{
"error": {
"reason": "Invalid Query",
"details": "invalid to get doubleValue from value of type TIME",
"type": "ExpressionEvaluationException"
},
"status": 400
}
What is the expected behavior?
To report an error on the incompatible argument, resembling the following:
{
"error": {
"reason": "Invalid Query",
"details": "unix_timestamp function expected {[], [DOUBLE],[DATE],[TIMESTAMP]}, but get [TIME]",
"type": "ExpressionEvaluationException"
},
"status": 400
}
yuancu
changed the title
[BUG] Mismatch in declared and actual function argument types
[BUG] Mismatch in documented and actual function argument types
Mar 31, 2025
unix_timestamp(time('\''12:00:00'\'')) triggers implicit conversion, converting input parameters from time type to timestamp type. I propose removing this implicit conversion in 3.0.0-beta for 4 reasons:
The implicit conversion from time to timestamp type can easily lead to semantic errors. Most databases do not allow such implicit conversion. For example, in PostgreSQL.
select unix_timestamp(time '12:00:00' );
will fail with
LINE 1: select unix_timestamp(time '12:00:00' );
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
What is the bug?
I found there are mismatches between declared and actual accepting argument types in datetime functions.
The documentation of datetime functions: https://github.com/opensearch-project/sql/blob/main/docs/user/ppl/functions/datetime.rst
Accepting TIME, but not declared to do so
NOT Accepting TIMESTAMP, but declared to do so:
How can one reproduce the bug?
Steps to reproduce the behavior:
Send a PPL request to local cluster
It returns a value, assuming that the date is today. However, TIME is not supported as an argument for
unix_timestamp
. This behavior is undocumented.Moreover, when I pass a time from the index, it reports an error, but with unexpected error message:
Send a ppl query:
source=dates | head 1 | eval d = unix_timestamp(time) | fields d
, wheretime
is of type TIME.It reports an error like below:
What is the expected behavior?
To report an error on the incompatible argument, resembling the following:
What is your host/environment?
The text was updated successfully, but these errors were encountered: