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

Unable to call set_result_subtype at the appropriate time #1157

Closed
mullr opened this issue Apr 5, 2022 · 6 comments · Fixed by #1160
Closed

Unable to call set_result_subtype at the appropriate time #1157

mullr opened this issue Apr 5, 2022 · 6 comments · Fixed by #1160

Comments

@mullr
Copy link

mullr commented Apr 5, 2022

I see that you have added a binding for sqlite3_result_subtype, which is great, that's exactly the thing I need! However, this needs be called /after/ sqlite3_result_* in order to take effect, which isn't currently possible.

Do you have something in mind for how to do it? I'd be happy to implement it if it's reasonably straightforward.

@mullr
Copy link
Author

mullr commented Apr 5, 2022

I've hacked around this over at https://github.com/mullr/rusqlite/tree/set_result_hack by adding a FunctionFlag value to ignore the return value of the user provided function. I also exposed set_result on Context, so user code can call set_result and then set_result_subtype.

As the branch name suggests, this not that nice. But maybe it's ok? The surrounding types don't leave much room for maneuvering without some pretty major surgery, afaict.

@gwenn
Copy link
Collaborator

gwenn commented Apr 6, 2022

What about:

pub trait SubType : ToSql {
   fn sub_type(&self) -> Option<c_uint> {
     None
   }
}

?

@mullr
Copy link
Author

mullr commented Apr 6, 2022

That seems like a great API. It would either require that the create_*_function calls use that as a type constraint instead of ToSql, breaking existing users, or adding new variants of create_*_function that allow this type. Is one of those preferable?

@gwenn
Copy link
Collaborator

gwenn commented Apr 7, 2022

@mullr Could you please check #1160 ?

@mullr
Copy link
Author

mullr commented Apr 7, 2022

@gwenn #1160 looks good to me. Thanks for putting that together!

@gwenn
Copy link
Collaborator

gwenn commented Feb 17, 2024

Version 0.31.0 released

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants