Message-ID: <4ED9418C.1070801@enterprisedb.com>
Date: Fri, 02 Dec 2011 23:22:20 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15
MIME-Version: 1.0
To: =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer@wulczer.org>
CC: Mika Eloranta <mel@ohmu.fi>, pgsql-hackers@postgresql.org
Subject: Re: PL/Python SQL error code pass-through
References: <0174B71F-7940-4819-BDC8-95EC8C9BA833@ohmu.fi>
	<4ECDFB26.1090203@wulczer.org> <4ECE5FA5.6060506@enterprisedb.com>
	<4ECEBDA5.4000600@wulczer.org>
In-Reply-To: <4ECEBDA5.4000600@wulczer.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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