Handle CREATE [TEMPORARY|TEMP] VIEW [IF NOT EXISTS]

[gabivlj]

Tried giving this a go as I encountered the same problem as #976! Let me know what you folks think or if there is any changes needed!

Closes #976

[alamb]

Looks good to me -- thank you very much @gabivlj 🙏

[coveralls]

Pull Request Test Coverage Report for Build 6423607217

• 79 of 82 (96.34%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.05%) to 87.321%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/parser/mod.rs	5	6	83.33%
src/ast/mod.rs	4	6	66.67%

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

Totals
Change from base Build 6423568746:	0.05%
Covered Lines:	16728
Relevant Lines:	19157

---

💛 - Coveralls

[alamb]

The CI failures do not appear to be related to this PR -- see #995

[alamb]

@gabivlj if you can merge up from main, I think the CI will pass on this PR.

I tried to do it but I do not have permissions:

alamb@MacBook-Pro-8:~/Software/sqlparser-rs$ git merge upstream/main
Auto-merging src/ast/mod.rs
Auto-merging src/parser/mod.rs
Merge made by the 'ort' strategy.
 src/ast/mod.rs     |  2 +-
 src/ast/visitor.rs |  2 +-
 src/parser/mod.rs  | 12 ++++++++----
 3 files changed, 10 insertions(+), 6 deletions(-)
alamb@MacBook-Pro-8:~/Software/sqlparser-rs$ git push
Enumerating objects: 29, done.
Counting objects: 100% (28/28), done.
Delta compression using up to 16 threads
Compressing objects: 100% (15/15), done.
Writing objects: 100% (15/15), 1.81 KiB | 371.00 KiB/s, done.
Total 15 (delta 11), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (11/11), completed with 8 local objects.
To github.com:gabivlj/sqlparser-rs.git
 ! [remote rejected] gabivlj/main -> gabivlj/main (permission denied)
error: failed to push some refs to 'github.com:gabivlj/sqlparser-rs.git'

[gabivlj]

Sure! Thanks for the heads up

[alamb]

Thanks again @gabivlj

[lovasoa]

thanks !

[lovasoa]

Is this on purpose ? Most other constructs do not generate parse errors when parsed with the "wrong" dialect. Is there a rule for how sqlparser handles that, or does every contributor do it their own way ?

I was under the impression that dialects allowed disambiguating syntax that would parse differently in different databases, but did not cause a parse error when parsing unambiguous syntax from one dialect with a different one.

@alamb

[gabivlj]

https://github.com/gabivlj/sqlparser-rs/blob/96c5979481536c6f6fe3193674059b2fff1d81b7/src/parser/mod.rs#L2984-L2990

For context, I took the idea from already existing RedshiftSqlDialect with_no_schema_binding. The intent here was excluding Dialects that do not support CREATE VIEW IF NOT EXISTS, for example the most similar feature for Postgresql is CREATE OR REPLACE VIEW as IF NOT EXISTS on a view is not supported there.

[lovasoa]

Yes, I see that. There does not seem to be a coherent rule over the entire codebase for whether database-specific syntax should cause a syntax error when parsed with a different dialect.

[alamb]

Yes, I see that. There does not seem to be a coherent rule over the entire codebase for whether database-specific syntax should cause a syntax error when parsed with a different dialect.

I agree this is not uniform in the codebase and I think sqlparser-rs is more permissive than most other parsers in the sense that it will parse SQL that would generate a syntax error in the original implementation. This is broadly consistent with the sentiment of https://github.com/sqlparser-rs/sqlparser-rs#syntax-vs-semantics

In general I expect that the GenericDialect will parse the union of all other dialects, as long as they aren't in conflict with each other (e.g. the rules on how to parse strings vs identifiers differ in some dialects)