On Tue, Aug 3, 2010 at 11:32 PM, J. Greg Davidson j...@well.com wrote:
Hi fellow PostgreSQL hackers,
First, a thank you to Merlin for commenting on my earlier post!
I've run into another dangerous problem since the earlier post.
I began converting from the plpgsql loop idiom for merging data
On Wed, 2010-08-04 at 11:12 -0400, Merlin Moncure wrote:
The infinite loop check is good but you missed the most important
part: you need to be checking sqlerrm to see where the unique
violation is coming from. Your original issue was that some dependent
trigger was causing the error which
Hi fellow PostgreSQL hackers,
First, a thank you to Merlin for commenting on my earlier post!
I've run into another dangerous problem since the earlier post.
I began converting from the plpgsql loop idiom for merging data
into a COALESCE(find(), create(), find()) idiom and ran into a
problem
On Wed, Jul 28, 2010 at 5:27 PM, J. Greg Davidson j...@well.com wrote:
Hi fellow PostgreSQL hackers,
I just got burned by the idiomatic loop
documented in the PostgreSQL manual as
Example 39-2. Exceptions with UPDATE/INSERT
I have now replaced this standard idiom
with a safer one
On Thu, Jul 29, 2010 at 10:06 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Jul 28, 2010 at 5:27 PM, J. Greg Davidson j...@well.com wrote:
Hi fellow PostgreSQL hackers,
I just got burned by the idiomatic loop
documented in the PostgreSQL manual as
Example 39-2. Exceptions with
Hi fellow PostgreSQL hackers,
I just got burned by the idiomatic loop
documented in the PostgreSQL manual as
Example 39-2. Exceptions with UPDATE/INSERT
I have now replaced this standard idiom
with a safer one described below.
What went wrong:
It seems that the table I was either
inserting
