Skip to content

Break up DDL and Query LogicalPlan variants #1281

@alamb

Description

@alamb

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
As mentioned on #1266 and #1266 (review), as we add more capabilities to DataFusion like CREATE TABLE AS SELECT and DROP TABLE it seems like there are now really two types of LogicalPlan variants:

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

Depending on the usecase, some DataFusion users will want to support the built in DDL (CreateTable, etc) and smoe will not. For example CREATE EXTERNAL TABLE could easily be a security hole for systems that want to use Datafusion to provide a SQL read-only access to their data. I worried about such a problem in IOx recently -- see https://github.com/influxdata/influxdb_iox/pull/3051

It would be great to split up the types of plans that come out of the planner so users of DataFusion (such as IOx) could be better sure that the DDL commands are not executed (unless they want the to be).

Describe the solution you'd like

Perhaps the SQLParser could produce something like

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

Where DDLPLan was like

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

**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.

**Additional context**
Add any other context or screenshots about the feature request here.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions