4 ms·
> Especially since last_insert_rowid() can never be free of race condition I think that's overstating it. It's per-connection, not per-database. If you don't s
by scottlamb 6y ago
> Especially since last_insert_rowid() can never be free of race condition
I think that's overstating it. It's per-connection, not per-database. If you don't share connections between threads, it's fine. If you keep the connection locked / checked out for the span of the two statement, it's fine. You're probably doing the latter anyway if you use transactions.
Returning looks nice, though! Particularly that it can return "one result row for each database row that is deleted, inserted, or updated" rather than just one.
- masklinn 6y ago> Returning looks nice, though! Particularly that it can return "one result row for each database row that is deleted, inserted, or updated" rather than just one. That… seems normal? Returning just one row would make no sense, how would even a trivial `RETURNING id` work otherwise?
- scottlamb 6y agoSure, but I'm comparing to last_insert_rowid(), which can't do that. Also, last_insert_rowid() (by definition) doesn't work with "without rowid" tables, where returning can.
- masklinn 6y agoAh I see, I was a bit confused because I'm used to RETURNING from pg and I've been waiting for sqlite to add it for a very long time. Especially since ON CONFLICT was added as it made the issue even worse.