As of now (scylladb/scylla-cqlsh@86a280a1a6c274c5266eaa69134c1af9574abcab), handle_statement() in cqlsh.py follows this logic at some point: if a statement starts with a keyword that has a corresponding custom handler, parse the statement. If parsing succeeds, hand over performing the statement to the handler; if parsing fails, performing the statement fails as well.
Although it's not a problem in most cases, it may be inconvenient in the case of DESCRIBE statements. Said statements are responsible for describing elements of the schema, as well as auth and service levels (in the upcoming patch: scylladb/scylladb#20168). If the set of those elements is extended in the future, we need to possibly update cqlsh as well. We want to avoid it.
We want to rely on the server and so we'd like to first send a query to it and only if it fails should we try to parse the statement and perform it "locally".
As of now (scylladb/scylla-cqlsh@86a280a1a6c274c5266eaa69134c1af9574abcab),
handle_statement()incqlsh.pyfollows this logic at some point: if a statement starts with a keyword that has a corresponding custom handler, parse the statement. If parsing succeeds, hand over performing the statement to the handler; if parsing fails, performing the statement fails as well.Although it's not a problem in most cases, it may be inconvenient in the case of DESCRIBE statements. Said statements are responsible for describing elements of the schema, as well as auth and service levels (in the upcoming patch: scylladb/scylladb#20168). If the set of those elements is extended in the future, we need to possibly update cqlsh as well. We want to avoid it.
We want to rely on the server and so we'd like to first send a query to it and only if it fails should we try to parse the statement and perform it "locally".
Suggested by @piodul