Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type discrepancy between QueryRowsResult::column_specs and PreparedStatement::get_result_set_col_specs #1132

Open
muzarski opened this issue Nov 26, 2024 · 1 comment
Assignees
Labels
API-breaking This might introduce incompatible API changes API-stability Part of the effort to stabilize the API
Milestone

Comments

@muzarski
Copy link
Contributor

The former returns ColumnSpecs<'_>, while the latter returns &[ColumnSpec<'_>].

In a sense, returned values represent the same thing - thus, the returned types should be the same or easily convertible into one another (currently ColumnSpecs constructor is pub(crate)).

@muzarski muzarski added API-breaking This might introduce incompatible API changes API-stability Part of the effort to stabilize the API labels Nov 26, 2024
@muzarski muzarski added this to the 0.16.0 milestone Nov 26, 2024
@wprzytula wprzytula assigned wprzytula and unassigned muzarski Dec 19, 2024
@Lorak-mmk Lorak-mmk modified the milestones: 0.16.0, 1.0.0 Feb 5, 2025
@Lorak-mmk
Copy link
Collaborator

One tiny problem with this. ColumnSpecs wrapper assumes that the lifetime of inner ColumnSpec is the same as the lifetime of the slice itself:

#[derive(Debug, Clone, Copy)]
pub struct ColumnSpecs<'res> {
    specs: &'res [ColumnSpec<'res>],
}

If we change the return type of PreparedStatement::get_result_set_col_specs to ColumnSpecs, then it sadly no longer returns ColumnSpec<'static> - it is limited to the lifetime of self.
How should we address this? And is the wrapper even necessary given that we gave up the idea of eliminating TableSpec from binding markers in prepared statement? @wprzytula

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API-breaking This might introduce incompatible API changes API-stability Part of the effort to stabilize the API
Projects
None yet
Development

No branches or pull requests

3 participants