Skip to content

Conversation

@viirya
Copy link
Member

@viirya viirya commented Nov 8, 2021

Which issue does this PR close?

Closes #1252.

Rationale for this change

What changes are included in this PR?

Add drop table support.

Are there any user-facing changes?

User can drop table by using the new syntax.

@github-actions github-actions bot added datafusion sql SQL Planner labels Nov 8, 2021
})
}
LogicalPlan::DropMemoryTable { name, if_exist, .. } => {
Ok(LogicalPlan::DropMemoryTable {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should handled the same as cases without input, like LogicalPlan::EmptyRelation

input: Arc<LogicalPlan>,
},
/// Drops an in memory table.
DropMemoryTable {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it should be called DropTable as we are also dropping external tables.

/// If the table exists
if_exist: bool,
/// Dummy schema
schema: DFSchemaRef,
Copy link
Member

Choose a reason for hiding this comment

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

i wonder if it's valuable to actually just attach the fetched table schema

Copy link
Member

Choose a reason for hiding this comment

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

otherwise you can just remove this placeholder

Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need a schema for dropping the table?

Copy link
Member Author

@viirya viirya Nov 8, 2021

Choose a reason for hiding this comment

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

yea, seems an empty schema is better here.

object_type: ObjectType::Table,
if_exists,
names,
cascade: _,
Copy link
Member

Choose a reason for hiding this comment

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

is it possible to add cascade and purge to the statement to the logical plan, or otherwise have a warning here saying that they do not take any effect

Copy link
Member Author

Choose a reason for hiding this comment

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

I've just added a comment here, is it okay?

LogicalPlan::Extension { node } => node.schema(),
LogicalPlan::Union { schema, .. } => schema,
LogicalPlan::CreateMemoryTable { input, .. } => input.schema(),
LogicalPlan::DropTable { schema, .. } => schema,
Copy link
Contributor

Choose a reason for hiding this comment

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

We could return an empty schema here instead of keeping it the plan node.

Copy link
Member Author

Choose a reason for hiding this comment

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

I tried creating an empty schema before, but schema returns &DFSchemaRef, so rustc complains about a reference to dropped temporary object.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, that is unfortunate but I think the comments in the LogicalPlan struct are reasonable

Copy link
Contributor

Choose a reason for hiding this comment

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

Hm. Another solution could be having / referencing a static object for an empty schema, but I'm ok with the current situation.

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thank you @viirya

The comments on this PR got me thinking there are are really two types of LogicalPlan variants:

  1. That can actually be compiled / run as a ExecutionPlan (e.g. LogicalPlan::Select)
  2. That must effectively be "interpreted" in the DataFrame (e.g. CreateTable, DropTable, etc)

It might be cool to split them up somehow.

Perhaps the SQLParser could produce something like

enum ParsedPlan {
  Query(LogicalPlan),
  DDL(DDLPlan)
}

Where DDLPLan was like

enum DDLPlan {
  CreateExternalTable {...}
  CreateMemoryTable {..},
  DropTable {..}
  ...
}

LogicalPlan::Extension { node } => node.schema(),
LogicalPlan::Union { schema, .. } => schema,
LogicalPlan::CreateMemoryTable { input, .. } => input.schema(),
LogicalPlan::DropTable { schema, .. } => schema,
Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, that is unfortunate but I think the comments in the LogicalPlan struct are reasonable

@Dandandan Dandandan merged commit 7060961 into apache:master Nov 10, 2021
@Dandandan
Copy link
Contributor

Thank you @viirya

@viirya
Copy link
Member Author

viirya commented Nov 10, 2021

Thank you @Dandandan @alamb @jimexist

@houqp houqp added the enhancement New feature or request label Nov 10, 2021
@houqp
Copy link
Member

houqp commented Nov 10, 2021

thanks @viirya , just in time for the 6.0.0 release :D

@alamb
Copy link
Contributor

alamb commented Nov 10, 2021

Filed #1281 to track the "split out the DDL commands" idea

jimexist pushed a commit to jimexist/arrow-datafusion that referenced this pull request Nov 13, 2021
* Add drop table support.

* Rename to DropTable.

* Remove undeclared crate.

* Fix clippy error.

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

Labels

enhancement New feature or request sql SQL Planner

Projects

None yet

Development

Successfully merging this pull request may close these issues.

support drop table SQL

5 participants