Add support for TABLE command in Postgresql#2364
Conversation
| ); | ||
|
|
||
| for sql in [ | ||
| "TABLE films WHERE x > 0", |
There was a problem hiding this comment.
might be interesting to test: TABLE db.schema.table is rejected.
There was a problem hiding this comment.
Currently it is accepted. Based on the existing design philosophy I thought the parser should be permissive on this and relies on downstream semantic analyzer to do verification. But I want to get your opinion on this and will be happy to make the change rejecting this with a trait method
There was a problem hiding this comment.
so this is fixed by your second commit 👍
| dialects.verified_stmt("TABLE films"); | ||
| // Schema-qualified. | ||
| dialects.verified_stmt("TABLE myschema.films"); | ||
| // Database-qualified (three-part name). |
There was a problem hiding this comment.
this is for MySQL, not PostgreSQL, right ? Maybe a subtle overlap with another PR to come for MySQL ?
There was a problem hiding this comment.
Yes, actually I will enable this command and add mysql testing in the next revision as well since this implementation works for both
Hi. FYI, we have similar plan at Data Bene for Oracle/PG. |
…SQL. MySQL and PostgreSQL limit to 2 (schema.table); the Generic and ANSI dialects remain permissive. Also enables supports_table_command() for MySQL with tests.
|
Eager to see this landing as I was about to fix it myself. Thanks! |
|
Hi @iffyio 👋 — this PR has a community approval and is passing, but the CI workflow needs maintainer approval to run (and it needs a committer review to merge). Could you take a look when you have a chance? Thanks! |
| /// Returns true if the dialect supports the `TABLE` command | ||
| /// (SQL:2016 `<explicit table>`). See [`ExplicitTable`]. | ||
| fn supports_table_command(&self) -> bool { | ||
| false | ||
| } | ||
|
|
||
| /// Returns true if the dialect supports Postgres inheritance modifiers | ||
| /// (`ONLY` prefix and trailing `*`) on the `TABLE` command. | ||
| /// See [`InheritanceModifier`]. | ||
| fn supports_explicit_table_inheritance_modifiers(&self) -> bool { | ||
| false | ||
| } | ||
|
|
||
| /// Returns the maximum number of dot-separated parts allowed in a | ||
| /// table name for the `TABLE` command. For example, `2` means only | ||
| /// `schema.table` is accepted; `3` would allow `catalog.schema.table`. | ||
| /// | ||
| /// Returns `None` if the dialect does not restrict the number of parts. | ||
| fn table_command_max_name_parts(&self) -> Option<usize> { | ||
| None |
There was a problem hiding this comment.
I think we should be able to drop these dialect methods, the latter two are a bit too specific I think, and in general since we're introducing an entirely new statement it should be fine to have the parser always accept the statement without it conflicting with other dialects
| pub table_name: Option<String>, | ||
| /// Optional schema/catalog name qualifying the table. | ||
| pub schema_name: Option<String>, | ||
| pub struct ExplicitTable { |
There was a problem hiding this comment.
hmm not sure if there's a need to rename Table (its not clear to me what we gain by doing so)?
| #[derive(Debug, Copy, Clone, PartialEq, PartialOrd, Eq, Ord, Hash)] | ||
| #[cfg_attr(feature = "serde", derive(Serialize, Deserialize))] | ||
| #[cfg_attr(feature = "visitor", derive(Visit, VisitMut))] | ||
| pub enum InheritanceModifier { |
There was a problem hiding this comment.
| pub enum InheritanceModifier { | |
| pub enum TableInheritanceModifier { |
| /// The (possibly schema-qualified) table name. | ||
| pub name: ObjectName, | ||
| /// Postgres inheritance modifier (`ONLY` or trailing `*`), if present. | ||
| pub inheritance: InheritanceModifier, |
There was a problem hiding this comment.
this should be an Option instead of introducing a custom None variant in the enum
| pub struct ExplicitTable { | ||
| /// The (possibly schema-qualified) table name. | ||
| pub name: ObjectName, | ||
| /// Postgres inheritance modifier (`ONLY` or trailing `*`), if present. |
There was a problem hiding this comment.
| /// Postgres inheritance modifier (`ONLY` or trailing `*`), if present. | |
| /// Inheritance modifier. |
the rest of the comment is duplicated, the pg part we can drop since other dialects can support it either now or in the future
| /// Postgres inheritance-hierarchy modifier for table references. | ||
| /// | ||
| /// Controls whether a query against a table includes rows from descendant | ||
| /// tables (inheritance children or partitions). See | ||
| /// <https://www.postgresql.org/docs/current/ddl-inherit.html>. |
There was a problem hiding this comment.
| /// Postgres inheritance-hierarchy modifier for table references. | |
| /// | |
| /// Controls whether a query against a table includes rows from descendant | |
| /// tables (inheritance children or partitions). See | |
| /// <https://www.postgresql.org/docs/current/ddl-inherit.html>. | |
| /// Inheritance-hierarchy modifier for table references. | |
| /// | |
| /// Controls whether a query against a table includes rows from descendant | |
| /// tables (inheritance children or partitions). | |
| /// [Postgres]: https://www.postgresql.org/docs/current/ddl-inherit.html. |
| } | ||
| Keyword::TABLE if self.dialect.supports_table_command() => { | ||
| self.prev_token(); | ||
| self.parse_query().map(Into::into) |
There was a problem hiding this comment.
which statement type is being returned?
Hi all. We're an AWS team using sqlparser-rs for MySQL/PG parsing and plan to contribute a series of dialect compatibility improvements. Happy to coordinate on approach.
Change Description:
This closes Issue: #742
Renamed Table struct → ExplicitTable. The original Table struct was created for only one specific use case: CREATE TABLE x AS TABLE y.
The new name matches is more precise and matches SQL:2016 terminology.
Grammar: https://www.postgresql.org/docs/current/sql-select.html#SQL-TABLE