Re: Transaction Snapshot Cloning
От | Tom Lane |
---|---|
Тема | Re: Transaction Snapshot Cloning |
Дата | |
Msg-id | 24795.1200502168@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Transaction Snapshot Cloning ("Florian G. Pflug" <fgp@phlo.org>) |
Ответы |
Re: Transaction Snapshot Cloning
|
Список | pgsql-hackers |
"Florian G. Pflug" <fgp@phlo.org> writes: > I seem to remember there being some pushback to the idea of changing the > semantics of "set transaction isolation read only" from "soft" to "hard" > semantics though - on the basis that it might break existing > applications. If that has changed (or my memory tricks me ;-) ) I'd > volunteer to create a patch for 8.4 to make "set transaction read only" > a hard constraint. AFAICT it would violate the SQL spec as well as breaking backward compatibility. SQL99 4.32 saith An SQL-transaction has an access mode that is either read-only or read-write. The access mode may be explicitlyset by a <set transaction statement> before the start of an SQL-transaction or by the use of a <starttransaction statement> to start an SQL- transaction; otherwise, it is implicitly set to the default access mode for the SQL-session before each SQL-transaction begins. If no <set session characteristics statement> hasset the default access mode for the SQL-session, then the default access mode for the SQL- session is read-write.The term read-only applies only to viewed tables and persistent base tables. That last sentence is the basis for exempting temp tables from the read-only restriction. I'm not sure what the most convenient user API would be for an on-demand hard-read-only mode, but we can't use SET TRANSACTION READ ONLY for it. It'd have to be some other syntax. Maybe just use a GUC variable instead of bespoke syntax? SET TRANSACTION is really just syntactic sugar for GUC SET operations anyway ... regards, tom lane
В списке pgsql-hackers по дате отправления: