Transaction isolation

[jimmycuadra]

Does Diesel allow control of the isolation level of a transaction? It doesn't appear that it does right now, in which case consider this a feature request!

Specifically, for my use case, I want to use the "serializable" transaction isolation level in Postgres for an operation where a transaction should fail if a value it read in a query has changed by the time the transaction is committed. In other words, it queries a table, and if the data returned matches the expected condition, adds a new row to another table, but that insert should fail if the row previously queried from the first table has changed. (If there's a better way to do that, I'm all ears!) In other other words, defending against a time of check to time of use error.

[sgrif]

So the main question that comes to mind with this feature is what the behavior should be when inside of a nested transaction. I guess the simplest answer would be to not support specifying the isolation level when starting the transaction, and instead just add support for SET TRANSACTION instead.

[jimmycuadra]

Any idea of the timetable for this? Is this a post-1.0 feature? I've got a few things I need it for already.

[jimmycuadra]

Also, it looks like I'm going to need PG's advisory locks. Should I open a separate issue for that, or shall we repurpose this one to cover support for all the various concurrency control mechanisms in PG?

[sgrif]

Seems like advisory locks can just be done with sql_function!. I'll try to get SET TRANSACTION support in the next release

[sgrif]

Taking this off the milestone. It's a relatively minor feature to add, but it's not super critical at the moment, as we don't offer a ton over `execute("SET TRANSACTION WHATEVER"), and I'm trying to get the 0.9 release wrapped up soon