Re: [PATCH] PL/Python: Add spidata to all spiexceptions
От | Robert Haas |
---|---|
Тема | Re: [PATCH] PL/Python: Add spidata to all spiexceptions |
Дата | |
Msg-id | CA+TgmoapBGbakb++4JQz-AVDyvCENGDM61dQSOp7WSD4MC1U5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] PL/Python: Add spidata to all spiexceptions (Jan Urbański <wulczer@wulczer.org>) |
Ответы |
Re: [PATCH] PL/Python: Add spidata to all spiexceptions
|
Список | pgsql-hackers |
On Wed, Oct 31, 2012 at 5:33 AM, Jan Urbański <wulczer@wulczer.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
В списке pgsql-hackers по дате отправления: