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 whic
On Tue, Aug 3, 2010 at 11:32 PM, J. Greg Davidson 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
> into
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 with
On Thu, Jul 29, 2010 at 10:06 AM, Merlin Moncure wrote:
> On Wed, Jul 28, 2010 at 5:27 PM, J. Greg Davidson 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 hav
On Wed, Jul 28, 2010 at 5:27 PM, J. Greg Davidson 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 described b
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 i
