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 <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
commit 3472a2b0565ad0302e5ea47e49a95305c2b07f64
Author: Bruce Momjian <bruce@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>