> On 3 sep 2014, at 16:20, Robert Haas <robertmhaas@gmail.com> wrote:
>
>> On Mon, Sep 1, 2014 at 5:08 AM, Joel Jacobson <joel@trustly.com> wrote:
>>> On Sat, Jul 26, 2014 at 8:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Basically my point is that this just seems like inventing another way to
>>> do what one can already do with RAISE, and it doesn't have much redeeming
>>> social value to justify the cognitive load of inventing another construct.
>>
>> The main difference is with RAISE EXCEPTION 'OK'; you cannot know if
>> it was *your* line of code which throw the 'OK'-exception or if it
>> came from some other function which was called in the block of code.
>
> The real problem here is that if you're using PL/pgsql exceptions for
> control-flow reasons, you are taking a huge performance hit for that
> notational convenience. I do agree that the syntax of PL/pgsql is
> clunky and maybe we should fix that anyway, but I honestly can't
> imagine too many people actually wanting to do this once they realize
> what it does to the run time of their procedure (and in some cases,
> the XID-consumption rate of their database).
Exceptions in plpgsql is indeed an exception itself :-)
There are a few use cases when they are crucial though, I would say I
use this code pattern in 0.1% of all functions, but still, when I need
this, it gets ugly.
Glad to hear you might consider the idea of fixing this.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
