"Florian G. Pflug" <[EMAIL PROTECTED]> 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
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
