Do not silently ignore unsupported CREATE TABLE and CREATE VIEW syntax

[alamb]

Which issue does this PR close?

Closes #12449

Rationale for this change

@hailelagi fixed the bug for TEMPORARY in #12439 🙏

While reviewing #12439 I noticed there are some other clauses that are ignored too

For example the CLUSTER BY clause is totally ignored:

> create table  foo(x int) cluster by x;
0 row(s) fetched.
Elapsed 0.009 seconds.

We should reject this with an explicit error rather than silently ignoring it

What changes are included in this PR?

Changes:

1. Change sqlparser to error on fields which are currently ignored

Are these changes tested?

Are there any user-facing changes?

[alamb]

I removed the .. from this match statement and then let github copilot write the checks for all the clauses.

[comphead]

Thanks for doing this. Now it is clear what exactly not yet supported

[comphead]

What do you think if I create a ticket so we can cover this in user doc as well?

[alamb]

What do you think if I create a ticket so we can cover this in user doc as well?

Sure -- sounds like a good idea. What do you mean by "this"? Do you mean how DataFusion handles TEMPORARY tables?

[alamb]

I plan to hold off on merging this PR until the 42 release is made, to avoid introducing some regression at the last moment

[comphead]

What do you think if I create a ticket so we can cover this in user doc as well?

Sure -- sounds like a good idea. What do you mean by "this"? Do you mean how DataFusion handles TEMPORARY tables?

The idea was to document which features out of Create Table are not supported. Now it can be described pretty easily from the code you created

[alamb]

What do you think if I create a ticket so we can cover this in user doc as well?

Sure -- sounds like a good idea. What do you mean by "this"? Do you mean how DataFusion handles TEMPORARY tables?

The idea was to document which features out of Create Table are not supported. Now it can be described pretty easily from the code you created

I see -- I think my preference would be to document what features are supported (likely because I am being lazy) as well as the fact that the number of strange syntaxes that sqlparser-rs might accept in the future is not bounded.

[phillipleblanc]

strange syntaxes that sqlparser-rs might accept in the future

😆

[alamb]

strange syntaxes that sqlparser-rs might accept in the future

😆

One of my conclusions after reviewing many Prs in sqlparser-rs is that the breadth of SQL dialects is staggering. Staggering!!!

[alamb]

Thanks again everyone!