snowflake: add support for TRANSIENT keyword

[mobuchowski]

This PR adds support for Snowflake's TRANSIENT tables: https://docs.snowflake.com/en/user-guide/tables-temp-transient#transient-tables.

Snowflake grammar: https://docs.snowflake.com/en/sql-reference/sql/create-table#syntax

Signed-off-by: Maciej Obuchowski [email protected]

[coveralls]

Pull Request Test Coverage Report for Build 4206676074

• 15 of 18 (83.33%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.002%) to 86.055%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/ast/helpers/stmt_create_table.rs	5	6	83.33%
src/ast/mod.rs	2	3	66.67%
src/parser.rs	2	3	66.67%

Files with Coverage Reduction	New Missed Lines	%
src/ast/mod.rs	1	78.06%

Totals
Change from base Build 4206644050:	0.002%
Covered Lines:	13262
Relevant Lines:	15411

---

💛 - Coveralls

[AugustoFKL]

Couldn't think of a better place to put this comment, so I'll leave it as general.

1. Can you please take a look into the linter? The CI is failing.
2. Considering the documentation you presented, the transient is exclusive to other keywords before the 'TABLE' keyword:

CREATE [ OR REPLACE ]
    [ { [ LOCAL | GLOBAL ] TEMP[ORARY] | VOLATILE } | TRANSIENT ]

Therefore, should the parse and print of it be flexible regarding both being present? You shouldn't accept CREATE LOCAL TRANSIENT TABLE, right...?

Finally, since this is something specific, what do you think about adding validation to check if the dialect is the SnoflakeDialect or the GenericDialect?

Thanks for the PR!

[mobuchowski]

@AugustoFKL the lint failures seem to be unrelated to my PR at all and I think #803 fixes them. If you want to see full green before approving or merging I'd wait until it gets merged and I'll rebase on top of it, to not duplicate any work.

Regarding validation, I've thought it's kind of to the contrary to project goals:

This crate provides only a syntax parser, and tries to avoid applying any SQL semantics, and accepts queries that specific databases would reject, even when using that Database's specific Dialect.

I, of course, can add it if we agree that validation and accepting keywords based on dialect is what we generally want to pursue.

[alamb]

Regarding validation, I've thought it's kind of to the contrary to project goals:

I think this PR's addition of TRANSIENT support is consistent with the rest of the project and its code and it is fine to add.

Thank for for the contribution @mobuchowski and @AugustoFKL (I really appreciate having a review prior to looking at these PRs -- it makes a big difference) ❤️

I took the liberty of merging up from main and fixing a small clippy lint in this PR to get a clean CI run

[mobuchowski]

Thanks @alamb!