Support INSERT INTO ... DEFAULT VALUES ...

[CDThomas]

This change adds support for DEFAULT VALUES in insert statements.

I'm specifically after Postgres support, but it looks like DEFAULT VALUES is part of the SQL grammar. It looks to be supported by SQLite and MSSQL at least as well (I haven't tested with these, though). I took a quick look at the MySQL and BigQuery docs and they don't seem to support DEFAULT VALUES (and there are probably others that I haven't checked as well).

This change includes a breaking change to the AST that makes the source field on Statement::Insert optional. This approach is based on the implementation in Postgres where both cols and selectStmt (which looks to be the Postgres AST's equivalent to source) are empty. I'm not completely sure if this is appropriate for all dialects, so I'm definitely interested in feedback here 🙏

[lovasoa]

Suggested change

	if source.is_none() && columns.is_empty() {
	if source.is_none() {

I think we should never print INSERT INTO my_table(my_column);, which is syntactically invalid.

INSERT INTO my_table(my_column) DEFAULT VALUES; should successfully round-trip through sqlparser, since it's a logical error, but not a syntax error.

[CDThomas]

Thanks for the review @lovasoa.

INSERT INTO my_table(my_column) DEFAULT VALUES; should successfully round-trip through sqlparser, since it's a logical error, but not a syntax error.

I thought about this a bit and double checked the SQL grammar and implementation in Postgres and both seem to make INSERT INTO my_table(my_column) DEFAULT VALUES; invalid at the syntax level. I think it'd make sense for sqlparser to make this scenario a syntax error as well, but I could be missing something.

I also tested a statement out with Postgres in a DB fiddle and confirmed that it raises a syntax error:

-- error: syntax error at or near "DEFAULT"
INSERT INTO test_table (test_column) DEFAULT VALUES;

What do you think?

[lovasoa]

You are right about postgres, but it's not a syntax error in sqlite.

And insert into t(x); is a syntax error everywhere anyway, so I think we should never emit that.

[CDThomas]

Ah interesting, I was not aware of the behaviour in SQLite.

I added some coverage for syntax errors with DEFAULT VALUES here. Do you think that behaviour looks reasonable?

[CDThomas]

Just noticed that there's a bug in this implementation.

My additions don't play well with after_columns for Hive here. Looks like INSERT INTO test_table DEFAULT VALUES (some_column) doesn't get rejected.

I'll move this back to draft while I fix that up and add some test cases for invalid syntax as well.

[CDThomas]

Just noticed that there's a bug in this implementation.

My additions don't play well with after_columns for Hive here. Looks like INSERT INTO test_table DEFAULT VALUES (some_column) doesn't get rejected.

I'll move this back to draft while I fix that up and add some test cases for invalid syntax as well.

Should be fixed by 4f334bd. This is ready for review again.

[coveralls]

Pull Request Test Coverage Report for Build 6935450177

• 89 of 90 (98.89%) changed or added relevant lines in 5 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.04%) to 87.729%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/parser/mod.rs	14	15	93.33%

Totals
Change from base Build 6935126371:	0.04%
Covered Lines:	17937
Relevant Lines:	20446

---

💛 - Coveralls

[alamb]

This looks good to me -- thank you @lovasoa for your review. @CDThomas can you possibly merge up from the main branch to get the CI passing on this PR and I'll merge it in?

[CDThomas]

Thanks again @alamb and @lovasoa. I've merged in main and CI is green.

[alamb]

Thanks again