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