From: Jan Urbański <wulczer@wulczer.org>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Mika Eloranta <mel@ohmu.fi>
Cc: pgsql-hackers@postgresql.org
Subject: Re: PL/Python SQL error code pass-through
Date: Thu, 24 Nov 2011 22:56:53 +0100
Message-ID: <4ECEBDA5.4000600@wulczer.org> (raw)
In-Reply-To: <4ECE5FA5.6060506@enterprisedb.com>
References: <0174B71F-7940-4819-BDC8-95EC8C9BA833@ohmu.fi>
<4ECDFB26.1090203@wulczer.org>
<4ECE5FA5.6060506@enterprisedb.com>
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:
>>> Hi all,
>>>
>>> [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.
>
> Thank you, both. Is there some other fields that we should propagate
> from the original error message that we're missing? Like, context and
> file/line information? Or are those left out on purpose? I wonder if we
> should have a more wholesale approach, and store the whole ErrorData
> struct somewhere, and only add some extra context information with
> errcontext().
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.
Cheers,
Jan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: wulczer@wulczer.org, heikki.linnakangas@enterprisedb.com, mel@ohmu.fi
Subject: Re: PL/Python SQL error code pass-through
In-Reply-To: <4ECEBDA5.4000600@wulczer.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox