Skip site navigation (1) Skip section navigation (2)

Re: PL/Python SQL error code pass-through

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jan Urbański <wulczer(at)wulczer(dot)org>
Cc: Mika Eloranta <mel(at)ohmu(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PL/Python SQL error code pass-through
Date: 2011-12-02 21:22:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 

> 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.


> 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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-12-02 22:09:40
Subject: Re: Patch - Debug builds without optimization
Previous:From: Kevin GrittnerDate: 2011-12-02 21:11:04
Subject: Re: FlexLocks

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group