Re: proposal: PL/Pythonu - function ereport

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

In response to

Responses

Browse pgsql-hackers by date

  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