Skip to content

Add support for TABLE command in Postgresql#2364

Open
yanghykevin wants to merge 4 commits into
apache:mainfrom
yanghykevin:table-command
Open

Add support for TABLE command in Postgresql#2364
yanghykevin wants to merge 4 commits into
apache:mainfrom
yanghykevin:table-command

Conversation

@yanghykevin

@yanghykevin yanghykevin commented Jun 4, 2026

Copy link
Copy Markdown

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

);

for sql in [
"TABLE films WHERE x > 0",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be interesting to test: TABLE db.schema.table is rejected.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this is fixed by your second commit 👍

Comment thread tests/sqlparser_common.rs Outdated
dialects.verified_stmt("TABLE films");
// Schema-qualified.
dialects.verified_stmt("TABLE myschema.films");
// Database-qualified (three-part name).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is for MySQL, not PostgreSQL, right ? Maybe a subtle overlap with another PR to come for MySQL ?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, actually I will enable this command and add mysql testing in the next revision as well since this implementation works for both

@c2main

c2main commented Jun 6, 2026

Copy link
Copy Markdown

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.

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.
@docteurklein

Copy link
Copy Markdown

Eager to see this landing as I was about to fix it myself. Thanks!

@yanghykevin

Copy link
Copy Markdown
Author

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!

Comment thread src/dialect/mod.rs
Comment on lines +1429 to +1448
/// 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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread src/ast/query.rs
pub table_name: Option<String>,
/// Optional schema/catalog name qualifying the table.
pub schema_name: Option<String>,
pub struct ExplicitTable {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm not sure if there's a need to rename Table (its not clear to me what we gain by doing so)?

Comment thread src/ast/query.rs
#[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 {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pub enum InheritanceModifier {
pub enum TableInheritanceModifier {

Comment thread src/ast/query.rs
/// The (possibly schema-qualified) table name.
pub name: ObjectName,
/// Postgres inheritance modifier (`ONLY` or trailing `*`), if present.
pub inheritance: InheritanceModifier,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be an Option instead of introducing a custom None variant in the enum

Comment thread src/ast/query.rs
pub struct ExplicitTable {
/// The (possibly schema-qualified) table name.
pub name: ObjectName,
/// Postgres inheritance modifier (`ONLY` or trailing `*`), if present.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// 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

Comment thread src/ast/query.rs
Comment on lines +311 to +315
/// 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>.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// 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.

Comment thread src/parser/mod.rs
}
Keyword::TABLE if self.dialect.supports_table_command() => {
self.prev_token();
self.parse_query().map(Into::into)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which statement type is being returned?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants