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

feat: return Row from iter_scan instead of mutating in-place #155

Closed
wants to merge 1 commit into from

Conversation

imor
Copy link
Contributor

@imor imor commented Sep 20, 2023

This PR changes the iter_scan method signature from fn iter_scan(&mut self, row: &mut Row) -> Result<Option<()>, E> to fn iter_scan(&mut self) -> Result<Option<Row>, E>. The new signature is better in that the user is forced to return a Row instead of updating the incoming row in-place, which they can forget.

@imor imor marked this pull request as ready for review September 20, 2023 13:28
@burmecia
Copy link
Member

The original design was to return a Row in iter_scan, but there was a performance issue with that design (see details #46), so we changed to use a borrowed Row in #48. IMO, we shouldn't cover this user negligence as it is the basic interface requirement, and can be easily identified.

@imor
Copy link
Contributor Author

imor commented Sep 21, 2023

Oh I see, reusing the row saves some allocations because the Vecs in the row don't need to grow again for each new row. Closing for now.

@imor imor closed this Sep 21, 2023
kamyshdm pushed a commit to dymium-io/supabase-wrappers that referenced this pull request Jun 17, 2024
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 this pull request may close these issues.

2 participants