From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Catalin Iacob <iacobcatalin(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(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: | 2016-01-13 18:40:14 |
Message-ID: | 56969A0E.7060008@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2016-01-13 19:07:20 | Re: pgindent-polluted commits |
Previous Message | Tom Lane | 2016-01-13 17:13:11 | Re: pgindent-polluted commits |