Re: proposal: PL/Pythonu - function ereport

<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>