chore(deps): Update sqlparser to 0.56

[Dimchikkk]

Which issue does this PR close?

• Closes Upgrade to sqlparser 0.56.0 #16405

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[Dimchikkk]

Without this change the test fails:

#[test]
fn test_order_by_to_sql_3() {
    let statement = generate_round_trip_statement(
        GenericDialect {},
        r#"SELECT id, first_name, substr(first_name,0,5) FROM person ORDER BY id, substr(first_name,0,5)"#,
    );
    assert_snapshot!(
        statement,
        @r#"SELECT person.id, person.first_name, substr(person.first_name, 0, 5) FROM person ORDER BY person.id ASC NULLS LAST, substr(person.first_name, 0, 5) ASC NULLS LAST"#
    );
}

In the previous version substr were hitting:

            SQLExpr::Function(function) => {
                self.sql_function_to_expr(function, schema, planner_context)
            }

now it's hitting:

            SQLExpr::Substring {
                expr,
                substring_from,
                substring_for,
                special: _,
                shorthand: _,
            } => self.sql_substring_to_expr(
                expr,
                substring_from,
                substring_for,
                schema,
                planner_context,
            ),

Open for suggestions if there is a better way to handle it.

[Dimchikkk]

Not sure if the new data types should be handled here or Unsupported SQL type is fine.

[Dimchikkk]

(converted to draft while I'm investigating CI failures)

[Dimchikkk]

(one of the test failures is related to #1898 and would be fixed if that patch is backported to 0.56)

[Dimchikkk]

FIXME

[crepererum]

As an apache project, we should probably not depend on a personal repository where an individual controls the branches without any additional checks -- not because I personally distrust you but because the OSS world has seen its fair share of supply chain attacks and we should use best practice. I see two options forward:

• use a branch within the apache org repo instead of your personal one
• actually publish a 0.56.1 backport release to crates.io

I would prefer the 2nd option. CC @alamb

[alamb]

I think publishing a 0.56.1 release of sqlparser makes sense to me. Perhaps we can file a ticket in the sqlparser repo to track.

I am happy to run the process

Another alternative is to release the next release (0.57.0) and just skip 0.56.0 entirely in Datafusion

[crepererum]

I think not jumping multiple releases would be nice, so I've filed apache/datafusion-sqlparser-rs#1952

[Dimchikkk]

@crepererum thanks for creating the issue for releasing 0.56.1!

I changed the link to my personal repo just to test that all CI checks pass, surely I change it back to official 0.56.1 once it is released.

[alamb]

I will work on the release tomorrow -- hopefully we'll have it released by early next week

[alamb]

I think it is impossible to backport the fix in a semver compatible way. See apache/datafusion-sqlparser-rs#1952

I will instead accelerate the timeline for releasing 0.58.0

• Release sqlparser-rs version 0.58.0 around 2025-07-18 (was 2024-08-15) datafusion-sqlparser-rs#1886

[Dimchikkk]

@alamb yeah, it's definitely not a semver compatible.

[crepererum]

Just for the record: I'm OK with version jumping (i.e. directly upgrading to 0.58). I was just hoping that the intermediate step would be easier for @Dimchikkk or whoever is gonna pick this up.