On Dec8, 2010, at 20:39 , Kevin Grittner wrote: > The standard is tricky to read, but my reading of it is that only > "LOCAL" changes are allowed after the transaction is underway (which > I *think* effectively means a subtransaction), and those can't make > the setting less strict -- you're allowed to specify the same level > or more strict. There would be no harm from the perspective of > anything I'm working on to allow an in-progress transaction to be > set to what it already has, but that seems to invite confusion and > error more than provide a helpful feature, as far as I can tell. > I'm inclined not to allow it except at the start of a > subtransaction, but don't feel strongly about it.
Hm, I think being able to assert that the isolation level really is SERIALIZABLE by simply doing "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE" would be a great feature for SSI. 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. BTW, I hope to find some time this evening to review your more detailed proposal for "serializable read only deferrable" best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
