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

Re: [PATCH] PL/Python: Add spidata to all spiexceptions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jan Urbański <wulczer(at)wulczer(dot)org>
Cc: Oskari Saarenmaa <os(at)ohmu(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] PL/Python: Add spidata to all spiexceptions
Date: 2012-11-05 17:35:54
Message-ID: CA+TgmoapBGbakb++4JQz-AVDyvCENGDM61dQSOp7WSD4MC1U5A@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Oct 31, 2012 at 5:33 AM, Jan Urbański <wulczer(at)wulczer(dot)org> wrote:
> On 30/10/12 22:06, Oskari Saarenmaa wrote:
>>
>> PL/Python maps Python SPIError exceptions with 'spidata' attribute into
>> SQL
>> errors.  PL/Python also creates classes in plpy.spiexceptions for all
>> known
>> errors but does not initialize their spidata, so when a PL/Python function
>> raises such an exception it is not recognized properly and is always
>> reported as an internal error.
>
> You're right, I never thought of the possibility of user code explicitly
> throwing SPIError exceptions.
>
> The root issue is that PLy_elog will only set errcode if it finds the
> "spidata" attribute, but I think passing error details through that
> attribute is a kludge more than something more code should rely on.
>
> Here's an alternative patch that takes advantage of the already present (and
> documented) "sqlstate" variable to set the error code when handling SPIError
> exceptions.
>
> I also used your test case and added another one, just in case.

You should probably add this to the next CF so we don't forget about it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


In response to

Responses

pgsql-hackers by date

Next:From: Jan UrbańskiDate: 2012-11-05 18:07:16
Subject: Re: [PATCH] PL/Python: Add spidata to all spiexceptions
Previous:From: Robert HaasDate: 2012-11-05 17:33:05
Subject: Re: What are the advantages of not being able to access multiple databases with one connection?

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