From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Florian Pflug" <fgp(at)phlo(dot)org>, drkp(at)csail(dot)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: serializable read only deferrable |
Date: | 2010-12-08 20:20:01 |
Message-ID: | 20321.1291839601@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> Say you've written a trigger which enforces some complex
>> constraint, but is correct only for SERIALIZABLE transactions. By
>> simply sticking a "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE"
>> at the top of the trigger you'd both document that fact it is
>> correct only for SERIALIZABLE transactions *and* prevent
>> corruption should the isolation level be something else due to
>> a pilot error. Nice, simply and quite effective.
> It would be great to have a way within a trigger, or possibly other
> functions, to assert that the transaction isolation level is
> serializable. What gives me pause here is that the standard allows
> you to specify a more strict transaction isolation level within a
> subtransaction without error, so this way of spelling the feature is
> flirting with rather nonstandard behavior.
Yes. This is not the way to provide a feature like that.
> Is there maybe a better way to check this?
You can always read the current setting and throw an error if you
don't like it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kineticode Billing | 2010-12-08 20:21:31 | Re: Review: Extensions Patch |
Previous Message | Kineticode Billing | 2010-12-08 20:18:53 | Re: Review: Extensions Patch |