Re: proposal: PL/Pythonu - function ereport - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: proposal: PL/Pythonu - function ereport
Date
Msg-id 56969A0E.7060008@BlueTreble.com
Whole thread Raw
In response to Re: proposal: PL/Pythonu - function ereport  (Catalin Iacob <iacobcatalin@gmail.com>)
Responses Re: proposal: PL/Pythonu - function ereport  (Catalin Iacob <iacobcatalin@gmail.com>)
List pgsql-hackers
On 1/12/16 11:25 AM, Catalin Iacob wrote:
>> >The differentiation between Error and SPIError is wrong, because there isn't
>> >any difference in reality.
> 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.

IMHO the Error and Fatal classes should never have been committed, 
especially since they're undocumented. It's not the responsibility of 
this patch to remove them, but it certainly shouldn't dig the hole deeper.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgindent-polluted commits
Next
From: Mark Dilger
Date:
Subject: Re: pgindent-polluted commits