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

Re: PL/Python SQL error code pass-through

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
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-11-24 21:56:53
Message-ID: 4ECEBDA5.4000600@wulczer.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Thom BrownDate: 2011-11-24 21:57:11
Subject: Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID
Previous:From: Alvaro HerreraDate: 2011-11-24 21:50:35
Subject: Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID

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