Marko Tiikkaja wrote: > On 2011-02-17 8:37 PM +0200, Bruce Momjian wrote: > > Marko Tiikkaja wrote: > >> The problem with the "safe" way is that it's not safe if called in a > >> transaction with isolation level set to SERIALIZABLE. > > > > Good analysis. Documentation patch attached and applied. > > The "safe way" I was referring to above was the LOCK TABLE method, not > the one described in the documentation, so the remark about READ > COMMITTED in the patch should be removed. The first part looks fine though.
OK, sentence removed. Thanks. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
commit 3472a2b0565ad0302e5ea47e49a95305c2b07f64 Author: Bruce Momjian <br...@momjian.us> Date: Thu Feb 17 14:24:14 2011 -0500 Remove doc mention about read committed in upsert example. diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml index d2e74dc..d0672bb 100644 --- a/doc/src/sgml/plpgsql.sgml +++ b/doc/src/sgml/plpgsql.sgml @@ -2476,8 +2476,7 @@ SELECT merge_db(1, 'dennis'); </programlisting> This example assumes the <literal>unique_violation</> error is caused by the <command>INSERT</>, and not by an <command>INSERT</> trigger function - on the table. Also, this example only works in the default Read - Committed transaction mode. + on the table. </para> </example> </sect2>
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers