Olivier Mascia wrote: > "When a SAVEPOINT is the outer-most savepoint and it is not within > a BEGIN...COMMIT then the behavior is the same as BEGIN DEFERRED > TRANSACTION." > > What are the specific reasons for SAVEPOINT to be limited to BEGIN > DEFERRED in that case?
A BEGIN without a type is DEFERRED by default. > Could an optional syntax extension allow to specify IMMEDIATE (and > maybe EXCLUSIVE)? That syntax extension already exists. To specify the transaction type, write if _before_ the "SAVEPOINT", and surround it with "BEGIN" and ";": BEGIN IMMEDIATE; SAVEPOINT name; > When a "SAVEPOINT name [DEFERRED|IMMEDIATE|EXCLUSIVE]" is the outer- > most savepoint and it is not within a BEGIN...COMMIT then the behavior > is the same as BEGIN DEFERRED|IMMEDIATE|EXCLUSIVE TRANSACTION. > > In all other cases, the behavior will keep or upgrade the locks when > required and permitted, or fail (SQLITE_BUSY I think). This would be inconsistent if the outer transaction is already open and has a different type. (I don't think that relying on the automatic BEGIN would be a good idea. If your program does not know whether there is an active transaction, it already has problems.) Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
