Support arbitrary WITH options for CREATE [TABLE|VIEW]

[benesch]

Both Postgres and MSSQL accept this syntax, though the particular
options they accept differ.

[coveralls]

Pull Request Test Coverage Report for Build 273

• 94 of 98 (95.92%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.1%) to 90.832%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
tests/sqlparser_common.rs	36	40	90.0%

Files with Coverage Reduction	New Missed Lines	%
src/sqlparser.rs	1	91.26%

Totals
Change from base Build 267:	0.1%
Covered Lines:	3537
Relevant Lines:	3894

---

💛 - Coveralls

[nickolay]

I'd like to share a few thoughts on this, even though I don't have specific suggestions at this time:

• Both Postgres and MS support options without values (e.g. Postgres CREATE TABLE .. WITH (OIDS)). (MS additionally does not wrap the CREATE VIEW options in parentheses.)
• There's a standard WITH .. CHECK OPTION clause, distinct from the "WITH options" this PR implements, which makes for two sets of "with options"...
• If we want to support parsing statements that are not ;-delimited, care should be taken to distinguish WITH (options) at the end of a CREATE statement and a WITH cte AS at the beginning of the next query.

Some links to documentation (apparently these options can appear in other contexts, this is just a sample):

• Postgres:
  • CREATE TABLE (storage_parameter),
  • CREATE VIEW .. [ WITH ( view_option, ... ) ] AS .. [ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
• MS:
  • CREATE TABLE .. WITH (<table_option>, ...)
  • CREATE VIEW .. [ WITH <view_attribute>, ... ] AS ... [ WITH CHECK OPTION ]

[nickolay]

One thing I'd like to request is that you put a realistic SQL in the testcase (possibly moving it to a dialect-specific suite); the extensions can be implemented in a follow-up.

My idea with sqlparser_common.rs was that it runs (and must succeed) for all dialects. While currently only the lexer does dialect-specific processing, I imagine we'll come to a point where different dialects must parse a given SQL differently. I hoped that being clear about which dialect is supposed to handle certain non-common testcases would make that easier.

[benesch]

Ok, added a more realistic test case to the Postgres dialect. Thanks for the review!

[nickolay]

Thanks! Given that you kept WITH (foo = 'bar', a = 123) in the "general" tests I'd like to clarify - do you rely on a variation of this in your product?

[benesch]

do you rely on a variation of this in your product?

We do, yeah—but I think we'd be happy to declare that we are most closely aligned with the Postgres dialect, and ask for that dialect when we parse. I.e., you should definitely feel free to delete the general test case, or move it to the Postgres-specific test case.