Upgrade sqlparser dependency to 0.56.0

[piki]

This PR upgrades the sqlparser dependency to 0.56.0.

There were a few straightforward changes in the sqlparser API:

• Statement::Insert, Statement::Delete, and FromTable have an additional layer of wrapping
• Statement::Insert can now insert to a table or a table function
• MergeClause now puts its action in a separate action field
• Expr::Value now expects a ValueWithSpan

I took the opportunity to consolidate some duplicated code in constructing TableReference from various kinds of identifiers.

I also had to disable six tests for various dialects:

• DELETE <tables> FROM <tables> is no longer valid syntax in the Generic or BigQuery dialects
• The MsSql dialect treats TRUE and FALSE as identifiers rather than constants, so they don't get normalized

To support that, I added an all_dialects_except(...) helper to the test suite.

cargo fmt and cargo clippy both pass.

[takaebato]

The changes and improvements look great! Thank you so much for your work!

(This is unrelated to this change, but I find it odd that GenericDialect cannot parse DELETE <tables> FROM <tables>. As far as I remember, the design policy was that GenericDialect should be able to parse anything that other dialects can. I’ll open an issue on sqlparser-rs about this.)

Thanks again!

[piki]

I find it odd that GenericDialect cannot parse DELETE <tables> FROM <tables>. As far as I remember, the design policy was that GenericDialect should be able to parse anything that other dialects can.

Looks like sqlparser-rs broke that in #1120 while making the FROM keyword optional for DELETEs on BigQuery. Basically, Generic now handles only BigQuery-style DELETEs, while we actually want Generic to support both kinds of statements:

• DELETE [FROM] table [alias] WHERE condition (like BigQuery)
• DELETE tables FROM table WHERE condition (like all the other dialects)

But not these, which are a reduce/reduce conflict:

• DELETE tables table WHERE condition
• DELETE table alias WHERE condition

So you can't just make the expect_keyword_is(Keyword::FROM) optional, because then statements like the above could parse under two different rules.

I think it might be best to write two versions of parse_delete, rather than keep trying to make one function handle the union of two different grammars.

[takaebato]

@piki

Thanks for the clarification!
I’m not sure if I’ll be able to work on it myself…
Leaving a comment on the issue I opened would be super helpful for anyone tackling it :)

[piki]

Done: apache/datafusion-sqlparser-rs#1846 (comment)