Expand description
The rules of an interactive transaction, as a pure state machine: what an open or failed transaction admits, where it stands afterwards, and which savepoints it holds. Whatever holds the connection applies them.
Enums§
- Next
- Where the slot goes after an operation.
- Outcome
- How an operation that ran came back: fine, refused before reaching the server (the transaction is untouched), or failed on the server (which aborts the transaction).
- Phase
- Where an open transaction stands. After a statement error Postgres has aborted the transaction and only a rollback (to a savepoint or whole) is accepted.
- Savepoint
Op - SlotOp
Functions§
- admit
- Whether
opmay run inphase; a failed transaction answers every statement, savepoint and release with the error Postgres would give. - in_
failed_ transaction - What a failed transaction answers until it is rolled back.
- invalid_
savepoint - isolation_
sql - next
- The slot’s phase after an admitted
opran withoutcome. Commit and rollback end the transaction whatever happened; a server error inside it aborts it; a successful rollback to a savepoint recovers it. - parameters_
outside_ transaction - Parameters on a statement that cannot be prepared inside a transaction.
- rolled_
back_ by_ commit - A
COMMITof a failed transaction, which the server answers by rolling it back. - savepoint_
sql - The SQL for a savepoint operation, when the name it refers to exists:
RELEASEandROLLBACK TOan unknown savepoint would abort the whole transaction on the server, so they are refused first. - savepoints_
after - The savepoint stack after a successful operation:
RELEASEdrops the savepoint and every later one,ROLLBACK TOkeeps it and drops the later ones. - transaction_
control_ refused - Transaction control inside a statement, which the host owns.
- transaction_
limit - transaction_
not_ found - unknown_
savepoint - valid_
savepoint - Savepoint names are interpolated into SQL, so only the SDK’s own
sp_{depth}shape is accepted.