Re: plperl and/or insert trigger problem

From: Richard Huxton <dev(at)archonet(dot)com>
To: Bart Degryse <Bart(dot)Degryse(at)indicator(dot)be>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: plperl and/or insert trigger problem
Date: 2007-06-06 14:04:42
Message-ID: 4666BEFA.2070305@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bart Degryse wrote:
> Using DBI->err was a leftover from earlier testing. $dbh_pg->err is of course better. But it doesn't solve the problem.
>
> I'm not sure what you mean with your second remark.
> The call to my function ( SELECT dbi_insert3(); ) is one transaction I suppose.
> According to the documentation on execute_for_fetch (http://search.cpan.org/~timb/DBI-1.48/DBI.pm#execute_for_fetch) however
> an execute is done for every fetched record and @tuple_status should contain the error message associated with each failed execute.

I was wondering if there was a hidden BEGIN...COMMIT sneaking into the
process somewhere - either from execute_for_fetch() or in the context of
using DBI from within plperl. Reading back through, you say that the
"good" rows get inserted, so that can't be the case.

The only other reasons that spring to mind are:
1. A bug in your looping through tuple-status
2. A bug in execute_for_fetch() filling the tuple-status array.

What happens if you elog the whole array (just to get the ref numbers) -
that should show whether DBI is filling the array incorrectly.

--
Richard Huxton
Archonet Ltd

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2007-06-06 14:10:22 Re: Like operator
Previous Message Robert Bernier 2007-06-06 13:45:34 Re: New Live CD needed