LucaCappelletti94 commented on PR #2592:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/2592#issuecomment-5853833221
Downstream code can keep destructuring payloads on stable Rust if
`Statement` gets one accessor per variant that returns the unboxed payload,
generated by a small macro inside the crate, but yeah that also feels unclean
and heavily sub-optimal.
```rust
impl Statement {
pub fn as_create_table(&self) -> Option<&CreateTable> {
match self {
Self::CreateTable(create_table) => Some(create_table),
_ => None,
}
}
pub fn into_create_table(self) -> Option<CreateTable> {
match self {
Self::CreateTable(create_table) => Some(*create_table),
_ => None,
}
}
}
```
```rust
match pg_and_generic().one_statement_parses_to(sql, "").into_create_table() {
Some(CreateTable {
name,
columns,
constraints,
table_options,
if_not_exists: false,
external: false,
file_format: None,
location: None,
..
}) => { /* assertions unchanged */ }
_ => unreachable!(),
}
```
A `match` over several variants at once still binds the payload, as in
`Statement::Insert(insert) => insert.table`, and field access reads through the
`Box` transparently. On nightly, there is the experimental
`#![feature(deref_patterns)]` from rust-lang/rust#87121 but who knows when that
could stabilize.
An idea that could be viable, is to create a macro that generates BOTH the
`Statement` enum, and a `BoxedStatement` enum, and then we add a generic to the
parser chain, which would allow users to pick and choose which statement they
want to deserialize the SQL into - now that I think of it for a second longer,
this last idea seems very interesting to me as we could use it to make user
specify at compile time the pool of possible variants that they accept out of
the parser, possibly accelerating the code and certainly cleaning it.
I will play with this last idea and tell you whether anything nice pans out
of it. The idea of a compile-time typed restricted parser output feels very
Rust-y to me, and I suspect it could be done.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
