On 24.11.2011 23:56, Jan Urbański wrote:
> On 24/11/11 16:15, Heikki Linnakangas wrote:
>> On 24.11.2011 10:07, Jan Urbański wrote:
>>> On 23/11/11 17:24, Mika Eloranta wrote:
>>>> [PL/Python in 9.1 does not preserve SQLSTATE of errors]
>>>
>>> Oops, you're right, it's a regression from 9.0 behaviour.
>>>
>>> The fix looks good to me, I changed one place to indent with tabs
>>> instead of spaces and added a regression test.
(Forgot to mention earlier: I committed the patch to master and
REL9_1_STABLE)
> In case of SPI errors we're preserving the following from the original
> ErrorData:
>
> * sqlerrcode (as of Mika's patch)
> * detail
> * hint
> * query
> * internalpos
>
> that leaves us with the following which are not preserved:
>
> * message
> * context
> * detail_log
>
> The message is being constructed from the Python exception name and I
> think that's useful. The context is being taken by the traceback string.
> I'm not sure if detail_log is ever set in these types of errors,
> probably not? So I guess we're safe.
Ok.
> The problem with storing the entire ErrorData struct is that this
> information has to be transformed to Python objects, because we attach
> it to the Python exception that gets raised and in case it bubbles all
> the way up to the topmost PL/Python function, we recover these Python
> objects and use them to construct the ereport call. While the exception
> is inside Python, user code can interact with it, so it'd be hard to
> have C pointers to non-Python stuff there.
Hmm, can the user also change the fields in the exception within python
code, or are they read-only? Is the spidata attribute in the exception
object visible to user code?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
