Re: proposal: PL/Pythonu - function ereport
От | Pavel Stehule |
---|---|
Тема | Re: proposal: PL/Pythonu - function ereport |
Дата | |
Msg-id | CAFj8pRA2B8M3v+5-M=57yNY3Gj5ZqNk3_eLDoTdWsu97yt3x4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: PL/Pythonu - function ereport (Catalin Iacob <iacobcatalin@gmail.com>) |
Ответы |
Re: proposal: PL/Pythonu - function ereport
(Catalin Iacob <iacobcatalin@gmail.com>)
|
Список | pgsql-hackers |
<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">2015-12-03 7:04 GMT+01:00 Catalin Iacob <spandir="ltr"><<a href="mailto:iacobcatalin@gmail.com" target="_blank">iacobcatalin@gmail.com</a>></span>:<br /><blockquoteclass="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><spanclass="">On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule <<a href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>>wrote:<br /> > here is complete patch - regress testsfor all supported Python branches<br /><br /></span>I had a look at what changed in v10 since my last reviewed versionand<br /> indeed most of it is straightforward: renames from SPIError to Error.<br /> The patch also changes plpy.Fataland plpy.SPIError to inherit from<br /> the existing plpy.Error which is a backward incompatibility: catching<br/> a plpy.Error will now also catch SPIError and Fatal.<br /><br /> But by doing this I noticed plpy.Error alreadyexisted without the<br /> patch and raising plpy.Error(msg) is documented as equivalent to<br /> calling plpy.error(msg),similar for plpy.Fatal and plpy.fatal(). This<br /> patch makes it possible to raise plpy.Error with morearguments<br /> including keyword ones but doesn't change plpy.error(msg). And Fatal<br /> is not touched so it becomesinconsistent with Error.<br /><br /> So I now think the approach this patch took is wrong. We should<br /> insteadenhance the existing error and fatal functions and Error and<br /> Fatal exceptions to accept other arguments thatereport accepts (hint,<br /> sqlstate) and be able to pass all those as keyword parameters.<br /> SPIError should beleft unchanged as that's for errors raised by query<br /> execution not by the PL/Python user. This is also close to Pavel's<br/> original ereport proposal but by extending existing functionality<br /> instead of adding a new function andit covers Peter's observation<br /> that in Python the ereport function should be "raise an exception" as<br /> that'salready an alternative way of doing it.<br /></blockquote></div><br /><br /></div><div class="gmail_extra">I am sorry,I don't understand. Now due inheritance plpy.Fatal and plpy.SPIError has availability to use keyword parameters.<br/><br />postgres=# do $$ raise plpy.Fatal('AHOJ','NAZDAR');<br />$$ language plpythonu;<br />FATAL: 38000:plpy.Fatal: AHOJ<br />DETAIL: NAZDAR<br />CONTEXT: Traceback (most recent call last):<br /> PL/Python anonymouscode block, line 1, in <module><br /> raise plpy.Fatal('AHOJ','NAZDAR');<br />PL/Python anonymous codeblock<br /><br /></div><div class="gmail_extra">Regards<br /><br /></div><div class="gmail_extra">Pavel<br /></div></div>
В списке pgsql-hackers по дате отправления: