[BUG] match function allows any constant as field name.

[MaxKsyunz]

What is the bug?
The following queries are accepted by the SQL endpoint:
SELECT * FROM index WHERE MATCH(-3.14, "query")
SELECT * FROM index WHERE MATCH(interval 3 second, "query")

PPL endpoint is equally permissive.

What is the expected behavior?
SQL and PPL engines should only accept valid identifiers as field parameter of MATCH.

If the specified field does not exist, the user should receive the same error as they would if the field was used in SELECT clause.

This should be consistent across all single-field query functions described in #182.

[dai-chen]

Wondering if this is already fixed in latest support for MATCH in SQL engine v2?

[Yury-Fridlyand]

Just tested on one of the latest builds:

opensearchsql> SELECT * FROM calcs WHERE MATCH(-3.14, "query");
{'reason': 'Invalid SQL query', 'details': 'syntax error, expect AGAINST, actual EOF', 'type': 'ParserException'}

[dai-chen]

Just tested on one of the latest builds:

opensearchsql> SELECT * FROM calcs WHERE MATCH(-3.14, "query");
{'reason': 'Invalid SQL query', 'details': 'syntax error, expect AGAINST, actual EOF', 'type': 'ParserException'}

Thanks for the quick test! The query is rejected now but the syntax error seems unexpected? Or is just the message not accurate?

[Yury-Fridlyand]

The error comes from parser (ANTLR).
Actually, it fails on V2 engine, then in V1 and this error comes from V1.
The error aggregation and reporting is reworked in scope of #691. The error itself remains the same and it is not too verbose.

[dai-chen]

The error comes from parser (ANTLR). Actually, it fails on V2 engine, then in V1 and this error comes from V1. The error aggregation and reporting is reworked in scope of #691. The error itself remains the same and it is not too verbose.

I see. Probably because only identifier is allowed as first argument in v2, it fallback to legacy. This may go away when legacy is deprecated. Thanks

[dai-chen]

Can we close this now?

[forestmvey]

Can we close this now?

Yes this was fixed under #1067.