You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
edit:
This bug cannot be fixed as-is due to a requirement that we keep the table identifiers to prevent a duplicate column issue. See #5410 for more context on that issue
The PR that will close this issue only fixes it for the unparser scenario: #11082
Describe the bug
The schema that is the result of a UNION ALL should not have any table qualifiers, as the table information has effectively been erased and is no longer a valid reference.
Consider the following SQL:
SELECTtable1.fooFROM table1
UNION ALLSELECTtable2.fooFROM table2
The logical schema from this UNION ALL should be just foo, but it is currently taking the first input's schema directly, resulting in a schema of table1.foo.
This came up as an issue when trying to validate the unparser works correctly for UNION ALL statements, which I added in #10603
Slightly modifying the above example, if I add an ORDER BY clause to the input SQL:
SELECTtable1.fooFROM table1
UNION ALLSELECTtable2.fooFROM table2
ORDER BY foo
Then the resulting unparsed SQL will be:
SELECTtable1.fooFROM table1
UNION ALLSELECTtable2.fooFROM table2
ORDER BYtable1.foo
Because the unparser takes the schema directly from the Union node when writing out the column expressions.
To Reproduce
Running this test fails, when it should succeed:
#[test]
fn roundtrip_statement_with_dialect() -> Result<()> {
struct TestStatementWithDialect {
sql: &'static str,
expected: &'static str,
parser_dialect: Box<dyn Dialect>,
unparser_dialect: Box<dyn UnparserDialect>,
}
let tests: Vec<TestStatementWithDialect> = vec![
TestStatementWithDialect {
sql: "SELECT j1_id FROM j1
UNION ALL
SELECT tb.j2_id as j1_id FROM j2 tb
ORDER BY j1_id
LIMIT 10;",
expected: r#"SELECT j1.j1_id FROM j1 UNION ALL SELECT tb.j2_id AS j1_id FROM j2 AS tb ORDER BY j1_id ASC NULLS LAST LIMIT 10"#,
parser_dialect: Box::new(GenericDialect {}),
unparser_dialect: Box::new(UnparserDefaultDialect {}),
},
];
for query in tests {
let statement = Parser::new(&*query.parser_dialect)
.try_with_sql(query.sql)?
.parse_statement()?;
let context = MockContextProvider::default();
let sql_to_rel = SqlToRel::new(&context);
let plan = sql_to_rel
.sql_statement_to_plan(statement)
.unwrap_or_else(|e| panic!("Failed to parse sql: {}\n{e}", query.sql));
let unparser = Unparser::new(&*query.unparser_dialect);
let roundtrip_statement = unparser.plan_to_sql(&plan)?;
let actual = format!("{}", &roundtrip_statement);
println!("roundtrip sql: {actual}");
println!("plan {}", plan.display_indent());
assert_eq!(query.expected, actual);
}
Ok(())
}
Expected behavior
The table qualifiers are stripped from the schema of a UNION ALL LogicalPlan node.
Additional context
No response
The text was updated successfully, but these errors were encountered:
edit:
This bug cannot be fixed as-is due to a requirement that we keep the table identifiers to prevent a duplicate column issue. See #5410 for more context on that issue
The PR that will close this issue only fixes it for the unparser scenario: #11082
Describe the bug
The schema that is the result of a UNION ALL should not have any table qualifiers, as the table information has effectively been erased and is no longer a valid reference.
Consider the following SQL:
The logical schema from this UNION ALL should be just
foo
, but it is currently taking the first input's schema directly, resulting in a schema oftable1.foo
.This came up as an issue when trying to validate the unparser works correctly for UNION ALL statements, which I added in #10603
Slightly modifying the above example, if I add an ORDER BY clause to the input SQL:
Then the resulting unparsed SQL will be:
Because the unparser takes the schema directly from the Union node when writing out the column expressions.
To Reproduce
Running this test fails, when it should succeed:
Expected behavior
The table qualifiers are stripped from the schema of a UNION ALL LogicalPlan node.
Additional context
No response
The text was updated successfully, but these errors were encountered: