> Le 31 juil. 2019 à 18:53, Keith Medcalf <kmedc...@dessus.com> a écrit : > > I believe the idea would be to permit syntax something like: > > BEGIN IMMEDIATE [SHARED|[UPDATE]] [TRANSACTION]
Keith, I mostly share your view and I like the fact that the proposal uses SHARED and not READ or anything like that because the goal is not to propose some "read-only transaction". Yet, I fail to understand why: 1) you wrote it in the above way with [SHARED|[UPDATE]] syntax instead of: > BEGIN IMMEDIATE [SHARED|UPDATE] [TRANSACTION] and 2) why it would even matter to make provision for the optional UPDATE token. BEGIN IMMEDIATE [TRANSACTION] is the current semantic (immediately get RESERVED lock, as a first *write* would do within a DEFERRED TRANSACTION) BEGIN IMMEDIATE SHARED [TRANSACTION] would be the new semantic (immediately get SHARED lock, as a first *read* would do within a DEFERRED TRANSACTION) Forgetting the UPDATE sugar might make the syntax change simpler. The key issue around this discussion, is probably that it's a syntactic and semantic change that would not be available in older versions. Applications which have proxy code to begin transactions can very easily attempt some: SELECT ROWID FROM SQLITE_MASTER LIMIT 0 right after successfully running BEGIN [DEFERRED] [TRANSACTION] to emulate that IMMEDIATE SHARED feature. Oh by the way, the syntax might be the following alternative, closer to the current syntax diagrams of SQLite. I don't know if syntax compatibility provisions with other SQL implementations (and some of its 'standards') would dictate yours or this one. BEGIN [DEFERRED|SHARED|IMMEDIATE|EXCLUSIVE] [TRANSACTION] In the end, it surely is not a very necessary feature. :) — Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit besten Grüßen, Olivier Mascia _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
