mrob95 opened a new pull request, #2830:
URL: https://github.com/apache/arrow-datafusion/pull/2830
# Which issue does this PR close?
<!--
We generally require a GitHub issue to be filed for all bug fixes and
enhancements and this helps us generate change logs for our releases. You can
link an issue to this PR using the GitHub syntax. For example `Closes #123`
indicates that this PR will close issue #123.
-->
Closes #2529 .
# Rationale for this change
<!--
Why are you proposing this change? If this is already explained clearly in
the issue then this section is not needed.
Explaining clearly why changes are proposed helps reviewers understand your
changes and offer better suggestions for fixes.
-->
# What changes are included in this PR?
<!--
There is no need to duplicate the description in the issue here but it is
sometimes worth providing a summary of the individual changes in this PR.
-->
* Add the "SHOW CREATE TABLE" SQL command. It was suggested in #2529 to use
"SHOW CREATE VIEW" as MySQL does, but this is not supported by `sqlparser-rs`.
"SHOW CREATE TABLE" is [what spark uses for both tables and
views](https://docs.databricks.com/spark/latest/spark-sql/language-manual/sql-ref-syntax-aux-show-create-table.html)
and using the same command for both seems simpler than having separate ones.
* Pass SQL queries through `SqlToRel::statement_to_plan` and
`LogicalPlan::CreateView` to be stored on `ViewTable`, which is registered in
the catalog.
* Add a new `create_statement` method to the `TableProvider` trait that
allows table providers to optionally expose the SQL query used to create them.
* Add `LogicalPlan::ShowCreateTable` and `ShowCreateTableExec` to look the
table up, get the `TableProvider`, get the `create_statement` and output it.
This PR only supports views at the moment, but is designed to hopefully make
it fairly easy to extend to tables and potentially other data sources. They
would just need to implement `create_statement`.
Passing the SQL string down through `SqlToRel::statement_to_plan` alongside
the parsed `Statement` seemed a little awkward. An alternative would be to use
`format!("{}", statement)` which would produce valid SQL, but not the exact SQL
that was used to create the table/view.
Would be happy to take feedback on the structure of this if there is a
better way of doing it - I spent a while reading through `CreateView`,
`Explain`, `Analyze` etc to figure out where exactly the execution of this
should be handled but may have missed something :).
# Are there any user-facing changes?
<!--
If there are user-facing changes then we may require documentation to be
updated before approving the PR.
-->
<!--
If there are any breaking changes to public APIs, please add the `api
change` label.
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
