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

From Pavel Stehule
Subject Re: proposal: PL/Pythonu - function ereport
Date
Msg-id CAFj8pRAryCVOWmmKf9EOm7wWKPVCHUfGEDf5n35KhhE_+5DYmA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: PL/Pythonu - function ereport  (Catalin Iacob <iacobcatalin@gmail.com>)
List pgsql-hackers
Hi

2015-12-08 7:06 GMT+01:00 Catalin Iacob <iacobcatalin@gmail.com>:
On Thu, Dec 3, 2015 at 6:54 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Don't understand - if Fatal has same behave as Error, then why it cannot be
> inherited from Error?
>
> What can be broken?

Existing code that did "except plpy.Error as exc" will now also be
called if plpy.Fatal is raised. That wasn't the case so this changes
meaning of existing code, therefore it introduces an incompatibility.

I read some notes about Python naming convention

and we can use different names for new exception classes

* common ancestor - plpy.BaseError

* descendants - plpy.ExecError, plpy.SPIError, plpy.FatalError


It should to decrease compatibility issues to minimum. SPIError was used mostly for error trapping (see doc).

Is it ok for you?

Regards

Pavel

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: custom function for converting human readable sizes to bytes
Next
From: Bruce Momjian
Date:
Subject: Re: dynloader.h missing in prebuilt package for Windows?