Add Postgres-specific statements PREPARE, EXECUTE and DEALLOCATE #243
Conversation
…ific feature prepared statement.
Pull Request Test Coverage Report for Build 185417591
💛 - Coveralls |
src/ast/mod.rs
Outdated
| condition: Expr, | ||
| message: Option<Expr>, | ||
| }, | ||
| /// DEALLOCATE [ PREPARE ] { name | ALL } |
There was a problem hiding this comment.
This needs to be enclosed in backticks (as well as the ASSERT comment above -- sorry about missing that!), so that cargo doc output is properly formatted. Same below.
src/ast/mod.rs
Outdated
| name: Option<ObjectName>, | ||
| all: bool, |
There was a problem hiding this comment.
You shouldn't need to handle ALL separately, from the parser viewpoint, it's as good an object name, as any. Can name be schema-qualified? The docs are not clear on that.
There was a problem hiding this comment.
Sorry. I tried to check and test again. It is not schema-qualified. I will remove all and fix type of name to an Ident.
src/ast/mod.rs
Outdated
| Deallocate { | ||
| name: Option<ObjectName>, | ||
| all: bool, | ||
| prepare: bool, |
There was a problem hiding this comment.
This seems to be meaningless syntax. It's fine to keep it, but maybe note that PostgreSQL docs say it's ignored?
There was a problem hiding this comment.
Yes. The syntax is meaningless. But I think if we should output (format) the useless keyword PREPARE as the SQL passed into. What's your opinion?
src/ast/mod.rs
Outdated
| Statement::Deallocate { name, all, prepare } => { | ||
| f.write_str("DEALLOCATE ")?; | ||
| if *prepare { | ||
| f.write_str("PREPARE ")?; | ||
| } |
There was a problem hiding this comment.
I see we're inconsistent about that, but I believe using the same style as in the Statement::CreateTable branch will yield smaller code (especially we figure out the ALL vs object name question above).
src/ast/mod.rs
Outdated
| if !data_types.is_empty() { | ||
| write!(f, "({}) ", display_comma_separated(data_types))?; | ||
| } | ||
|
|
There was a problem hiding this comment.
Again, I know we're inconsistent about this, but it seems that we usually don't add blank lines in situations like this.
src/dialect/postgresql.rs
Outdated
| // We don't yet support identifiers beginning with "letters with | ||
| // diacritical marks and non-Latin letters" | ||
| (ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z') || ch == '_' | ||
| (ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z') || ch == '_' || ch == '$' |
There was a problem hiding this comment.
This doesn't match the documentation linked just above this line (Postgres seems to have $1 and $$comments$$, but I don't see how $foo is supposed to be parsed), so I'd like to split this separately. You should be able to keep it in a dialect of your own for now.
src/parser.rs
Outdated
| let name = self.parse_object_name()?; | ||
|
|
||
| let mut parameters = vec![]; | ||
| if self.expect_token(&Token::LParen).is_ok() { |
There was a problem hiding this comment.
We have confusingly named consume_token for that. Same below.
tests/sqlparser_postgres.rs
Outdated
|
|
||
| #[test] | ||
| fn parse_deallocate() { | ||
| let stmt = pg().verified_stmt("DEALLOCATE a"); |
There was a problem hiding this comment.
Use pg_and_generic() please.
|
Excellent, thank you! |
silathdiir
deleted the
add-prepare-execute-deallocate-as-top-level-statements
branch
3 participants
Closes #242
Adds top-statements
PREPARE,EXECUTEandDEALLOCATEfor Postgres-specific featureprepared statement.https://www.postgresql.org/docs/current/sql-prepare.html
https://www.postgresql.org/docs/current/sql-execute.html
https://www.postgresql.org/docs/current/sql-deallocate.html