Re: plperl and/or insert trigger problem
От | Richard Huxton |
---|---|
Тема | Re: plperl and/or insert trigger problem |
Дата | |
Msg-id | 4666BEFA.2070305@archonet.com обсуждение исходный текст |
Ответ на | Re: plperl and/or insert trigger problem ("Bart Degryse" <Bart.Degryse@indicator.be>) |
Ответы |
Re: plperl and/or insert trigger problem
|
Список | 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 failedexecute. 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
В списке pgsql-general по дате отправления: