You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remove outdated bits that claim shoddy SQL support and code
structure--we're much better on those fronts now! Also add a few
paragraphs about the current state of SQL compliance, why it's hard to
say anything detailed about SQL compliance, and what our long-term goals
are.
The goal of this project is to build a SQL lexer and parser capable of parsing SQL that conforms with the [ANSI SQL:2011](https://jakewheat.github.io/sql-overview/sql-2011-foundation-grammar.html#_5_1_sql_terminal_character) standard but also making it easy to support custom dialects so that this crate can be used as a foundation for vendor-specific parsers.
9
+
The goal of this project is to build a SQL lexer and parser capable of parsing
10
+
SQL that conforms with the [ANSI/ISO SQL standard][sql-standard] while also
11
+
making it easy to support custom dialects so that this crate can be used as a
12
+
foundation for vendor-specific parsers.
10
13
11
-
This parser is currently being used by the [DataFusion](https://github.com/andygrove/datafusion) query engine and [LocustDB](https://github.com/cswinter/LocustDB).
14
+
This parser is currently being used by the [DataFusion] query engine and
15
+
[LocustDB].
12
16
13
17
## Example
14
18
15
-
The current code is capable of parsing some trivial SELECT and CREATE TABLE statements.
SQL was first standardized in 1987, and revisions of the standard have been
43
+
published regularly since. Most revisions have added significant new features to
44
+
the language, and as a result no database claims to support the full breadth of
45
+
features. This parser currently supports most of the SQL-92 syntax, plus some
46
+
syntax from newer versions that have been explicitly requested, plus some MSSQL-
47
+
and PostgreSQL-specific syntax. Whenever possible, the [online SQL:2011
48
+
grammar][sql-2011-grammar] is used to guide what syntax to accept. (We will
49
+
happily accept changes that conform to the SQL:2016 syntax as well, but that
50
+
edition's grammar is not yet available online.)
51
+
52
+
Unfortunately, stating anything more specific about compliance is difficult.
53
+
There is no publicly available test suite that can assess compliance
54
+
automatically, and doing so manually would strain the project's limited
55
+
resources. Still, we are interested in eventually supporting the full SQL
56
+
dialect, and pull requests that improve compliance will almost certainly be
57
+
accepted.
58
+
59
+
If you are assessing whether this project will be suitable for your needs,
60
+
you'll likely need to experimentally verify whether it supports the subset of
61
+
SQL that you need. Please file issues about any unsupported queries that you
62
+
discover. Doing so helps us prioritize support for the portions of the standard
63
+
that are actually used.
64
+
65
+
### Supporting custom SQL dialects
66
+
67
+
This is a work in progress, but we have some notes on [writing a custom SQL
68
+
parser](docs/custom_sql_parser.md).
69
+
36
70
## Design
37
71
38
-
This parser is implemented using the [Pratt Parser](https://tdop.github.io/) design, which is a top-down operator-precedence parser.
72
+
This parser is implemented using the [Pratt Parser] design, which is a top-down
73
+
operator-precedence parser.
39
74
40
-
I am a fan of this design pattern over parser generators for the following reasons:
75
+
We are a fan of this design pattern over parser generators for the following
76
+
reasons:
41
77
42
-
- Code is simple to write and can be concise and elegant (this is far from true for this current implementation unfortunately, but I hope to fix that using some macros)
78
+
- Code is simple to write and can be concise and elegant
43
79
- Performance is generally better than code generated by parser generators
44
80
- Debugging is much easier with hand-written code
45
-
- It is far easier to extend and make dialect-specific extensions compared to using a parser generator
46
-
47
-
## Supporting custom SQL dialects
48
-
49
-
This is a work in progress but I started some notes on [writing a custom SQL parser](docs/custom_sql_parser.md).
81
+
- It is far easier to extend and make dialect-specific extensions
82
+
compared to using a parser generator
50
83
51
84
## Contributing
52
85
53
-
Contributors are welcome! Please see the [current issues](https://github.com/andygrove/sqlparser-rs/issues) and feel free to file more!
86
+
Contributors are welcome! Please see the [current issues] and feel free to file
87
+
more!
88
+
89
+
Please run [`cargo fmt`] to ensure the code is properly formatted.
54
90
55
-
Please run [cargo fmt](https://github.com/rust-lang/rustfmt#on-the-stable-toolchain) to ensure the code is properly formatted.
0 commit comments