> On 3 sep 2014, at 16:20, Robert Haas <robertmh...@gmail.com> wrote: > >> On Mon, Sep 1, 2014 at 5:08 AM, Joel Jacobson <j...@trustly.com> wrote: >>> On Sat, Jul 26, 2014 at 8:39 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
