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: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, 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: 2016-01-21 22:57:12
Message-ID: CAFj8pRA2siGfXi6e04sgqTmdt2pvdzaMAD338pxERzh+Kw1wvg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2016-01-14 17:16 GMT+01:00 Catalin Iacob <iacobcatalin(at)gmail(dot)com>:

> On Wed, Jan 13, 2016 at 7:40 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
> wrote:
> > On 1/12/16 11:25 AM, Catalin Iacob wrote:
> >> They're similar but not really the same thing. raise Error and
> >> plpy.error are both ways to call ereport(ERROR, ...) while SPIError is
> >> raised when coming back after calling into Postgres to execute SQL
> >> that itself raises an error. Now indeed, that executed SQL raised an
> >> error itself via another ereport(ERROR, ...) somewhere but that's a
> >> different thing.
> >
> >
> > Why should they be different? An error is an error. You either want to
> trap
> > a specific type of error or you don't. Having two completely different
> ways
> > to do the same thing is just confusing.
>
> With my (indeed limited) understanding, I don't agree they're the same
> thing and I tried to explain above why I think they're quite
> different. You may not agree. If they are different things, using
> different exception types is natural.
>
> Consider this call chain: SQL code 1 -> PL/Python code 1 -> SPI (via
> plpy.execute) -> SQL code 2 -> PL/Python code 2
>
> If I'm writing PL/Python code 1 and I want to raise an error toward
> SQL code 1 I use raise plpy.Error. plpy.SPIError is what I get if I
> call into SQL code 2 and that has an error. That error could indeed
> come from a plpy.Error thrown by PL/Python code 2 or it could come
> from a SQL syntax error or whatever. But the symmetry holds:
> plpy.Error is what you raise to stop the query and return errors to
> your SQL caller and plpy.SPIError is what you get back if you use SPI
> to execute some other piece of SQL which has an error. I *think* (I'm
> an internals newbie though so I could be wrong) that SQL code 1
> doesn't call into PL/Python code 1 via SPI so why would the latter use
> something called SPIError to inform the former about an error?
>

It is not correct - outside PLPython you got a Error (PostgreSQL error has
not any classes), and isn't important the raising class (Error or
SPIError). Inside PL/Python you will got SPIError or successors (based on
SQLcode).

Currently If I raise plpy.Error, then it is immediately trasformed to
PostgreSQL, and and then to SPIError and successors.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2016-01-21 23:24:06 Re: Combining Aggregates
Previous Message David Rowley 2016-01-21 22:47:26 Re: WIP: Covering + unique indexes.