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

Support the RETURNING clause #527

Open
cole-miller opened this issue Jul 22, 2023 · 2 comments
Open

Support the RETURNING clause #527

cole-miller opened this issue Jul 22, 2023 · 2 comments
Labels
Feature New feature, not a bug

Comments

@cole-miller
Copy link
Contributor

cole-miller commented Jul 22, 2023

We already have support for QUERY requests that modify the database, but the codepath that executes those requests assumes that all modifications are propagated to the WAL after the first call to sqlite3_step, which is not the case for a statement like DELETE FROM tab RETURNING col. Copying my comment from #472:

the "database changes occur during the first sqlite3_step" statement does not mean the changes will get flushed to the WAL at that point, they might remain in cache up until autocommit happens just before the sqlite3_step call that returns SQLITE_DONE. That makes things a bit difficult for us, since we want to VfsPoll and raft_apply before yielding any rows to the client. We could buffer all the rows up in memory, but that pretty much defeats the purpose of sending them to the client in batches. Alternatively, we could force a cache flush immediately after the first sqlite3_step.

@nginx-nickc
Copy link

hi, just wondering what's the current plan for this?

@MathieuBordere
Copy link
Contributor

hi @nginx-nickc it's currently not very high on the priority list, no ETA at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature, not a bug
Projects
None yet
Development

No branches or pull requests

3 participants