"Florian G. Pflug" <fgp(at)phlo(dot)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 explicitly set by a <set
transaction statement> before the start of an SQL-transaction or
by the use of a <start transaction 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> has set 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
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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-01-16 16:52:53|
|Subject: Re: Some ideas about Vacuum |
|Previous:||From: Mischa Sandberg||Date: 2008-01-16 16:41:42|
|Subject: postgresql in FreeBSD jails: proposal|