Re: Bug in plpython's Python Generators
От | Jan Urbański |
---|---|
Тема | Re: Bug in plpython's Python Generators |
Дата | |
Msg-id | 4CC3628D.8070405@wulczer.org обсуждение исходный текст |
Ответ на | Re: Bug in plpython's Python Generators (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Bug in plpython's Python Generators
Re: Bug in plpython's Python Generators |
Список | pgsql-hackers |
On 21/10/10 20:48, Alvaro Herrera wrote: > Excerpts from Alvaro Herrera's message of jue oct 21 15:32:53 -0300 2010: >> Excerpts from Jean-Baptiste Quenot's message of jue oct 21 09:20:16 -0300 2010: >> >>> I get this error when calling the function: >>> >>> test=# select foobar(); >>> ERROR: error fetching next item from iterator > I think all error cases in plpython need some improvement so that they > show the error message from Python. Right now they are ignored. > > ... and presumably somebody can fix the real bug that Jean-Baptiste hit, > too. AFAICS the error comes from PLy_function_handler disconnecting from SPI after calling into the Python code and then going ahead and reading the result from the iterator. The problem is that after calling PyIter_Next to resume the iterator and fetch the next value, it tries to do plpy.execute("select 1"), which fails because SPI is already disconnected. This probably means that a SRF should not disconnect from SPI until it has finished reading the result. The error handling in plpython is well-known to be a mess, hence the confusing error message that OP got. Another annoying thing is that SPI calls are not done in a subtransaction, which means you can't trap errors with a try/catch Python construct. I'm currently trying to get try/catch to work and might end up cleaning up error handling as well... but this can take me some time, so maybe someone should plug this particular hole right away. Cheers, Jan
В списке pgsql-hackers по дате отправления: