Re: proposal: PL/Pythonu - function ereport

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: proposal: PL/Pythonu - function ereport
Дата
Msg-id 56969A0E.7060008@BlueTreble.com
обсуждение исходный текст
Ответ на Re: proposal: PL/Pythonu - function ereport  (Catalin Iacob <iacobcatalin@gmail.com>)
Ответы Re: proposal: PL/Pythonu - function ereport  (Catalin Iacob <iacobcatalin@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgindent-polluted commits
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: pgindent-polluted commits