swalker@iglou.com wrote:
>
> So turning intially deferred on is a suitable solution? It seems
> to work OK in this simple test case.
It might change the behaviour of your application. If you set
the constraints deferred, they aren't checked at insert time
and the PK's aren't locked then either. So after doing the
INSERT or UPDATE successfully, someone else can still remove
the primary key referenced in your rows without any problems.
When you commit your transaction then, the deferred
constraints will fail and the COMMIT results in a ROLLBACK.
Jan
>
> On Tue, 2 Apr 2002, Stephan Szabo wrote:
> > The locks being grabbed are a bit stronger than they need to be
> > (if you want more info, there was a bit of discussion on -hackers
> > recently). The updates should block updates on parent of the
> > referenced row but don't need to block other child updates but there's
> > no current lock level that is quite right.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
