Re: proposal: PL/Pythonu - function ereport

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Catalin Iacob <iacobcatalin(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: PL/Pythonu - function ereport
Date: 2015-12-03 06:58:59
Message-ID: CAFj8pRA2B8M3v+5-M=57yNY3Gj5ZqNk3_eLDoTdWsu97yt3x4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-12-03 7:04 GMT+01:00 Catalin Iacob <iacobcatalin(at)gmail(dot)com>:

> On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > here is complete patch - regress tests for all supported Python branches
>
> I had a look at what changed in v10 since my last reviewed version and
> indeed most of it is straightforward: renames from SPIError to Error.
> The patch also changes plpy.Fatal and plpy.SPIError to inherit from
> the existing plpy.Error which is a backward incompatibility: catching
> a plpy.Error will now also catch SPIError and Fatal.
>
> But by doing this I noticed plpy.Error already existed without the
> patch and raising plpy.Error(msg) is documented as equivalent to
> calling plpy.error(msg), similar for plpy.Fatal and plpy.fatal(). This
> patch makes it possible to raise plpy.Error with more arguments
> including keyword ones but doesn't change plpy.error(msg). And Fatal
> is not touched so it becomes inconsistent with Error.
>
> So I now think the approach this patch took is wrong. We should
> instead enhance the existing error and fatal functions and Error and
> Fatal exceptions to accept other arguments that ereport accepts (hint,
> sqlstate) and be able to pass all those as keyword parameters.
> SPIError should be left unchanged as that's for errors raised by query
> execution not by the PL/Python user. This is also close to Pavel's
> original ereport proposal but by extending existing functionality
> instead of adding a new function and it covers Peter's observation
> that in Python the ereport function should be "raise an exception" as
> that's already an alternative way of doing it.
>

I am sorry, I don't understand. Now due inheritance plpy.Fatal and
plpy.SPIError has availability to use keyword parameters.

postgres=# do $$ raise plpy.Fatal('AHOJ','NAZDAR');
$$ language plpythonu;
FATAL: 38000: plpy.Fatal: AHOJ
DETAIL: NAZDAR
CONTEXT: Traceback (most recent call last):
PL/Python anonymous code block, line 1, in <module>
raise plpy.Fatal('AHOJ','NAZDAR');
PL/Python anonymous code block

Regards

Pavel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-12-03 07:06:02 Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
Previous Message konstantin knizhnik 2015-12-03 06:54:23 Re: Logical replication and multimaster