SHOW statements silently dropping quoted strings

[joocer]

When parsing generic SHOW statements such as SHOW FUNCTIONS or SHOW PARAMETERS, the parser creates a ShowVariable AST with each of the tokens after SHOW added as a variable node. This should allow functionality like SHOW FUNCTIONS LIKE '%date%' to be written by processing the AST even if the lexer doesn't understand what the query means.

However, this query SHOW FUNCTIONS LIKE '%date%' is parser to:

[
  {
    "ShowVariable": {
      "variable": [
        {
          "value": "FUNCTIONS",
          "quote_style": null
        },
        {
          "value": "LIKE",
          "quote_style": null
        }
      ]
    }
  }
]

Where the value in quotes is removed.

I think this is probably because SHOW queries, not followed by a well-known token (e.g. SHOW VARIABLES, SHOW COLUMNS) defaults to a variation of SHOW VARIABLE, and the tokens afterwards are expected to be formatted like Identifiers, but a quoted string doesn't match this expectation. If that is the case, I expect an error to be raised rather than silently dropping part of the query.

Thanks

[AugustoFKL]

Could you please specify the dialect in which you are based on? SHOW is not standard nor is on our standard SQL specifications, so to read more about it and get more context we need to know what are you based on.

[joocer]

Thanks Augusto,

The model I have tried to follow for this feature is SHOW VARIABLES from Trino and I recently submitted a PR to add this command.

Trino / Presto isn't a specific dialect on sqlparser-rs, I am using the MySQL dialect.

I think it's a bug that the tokens are silently dropped, and although I would find it useful if the tokens are returned in the AST, I appreciate this somewhat non-standard.

[AugustoFKL]

@joocer is this still required? It seems like had a merge already. What's the status? Can I give any help?

[joocer]

Hi Augusto, the PR was to solve the specific use case I had for a SHOW FUNCTIONS, it solved by creating a specific case for this query type but the underlying bug remains - if the parser encounters a string literal in a ShowVariables query the literal is silently dropped.

I have experience in multiple other languages to have been able to find the pattern in the existing code I could replicate to add ShowFunctions but I've never properly debugged or created in Rust to be able to fix the underlying problem quickly myself.