Skip site navigation (1) Skip section navigation (2)

Re: proposal: additional error fields

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: additional error fields
Date: 2012-05-01 14:25:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, May 1, 2012 at 8:21 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> I have to goals for 9.3. First goal is plpgsql_check_function, second
> goal is enhancing ErrorData and error management to support new
> previous discussion  is in thread

I have some concerns about the performance cost of this.  Now, you may
think that this is a dumb thing to be concerned about, but some
testing I've done seems to indicate that MOST of the cost of rolling
back a subtransaction is the cost of generating the error string, and
this is why PL/pgsql exception blocks are slow, and I actually do
think that the slowness of PL/pgsql exception blocks is a real issue
for users.  It certainly has been for me, in the past.  So adding 9
more fields that will have to be populated on every error whether
someone cares about them or not is a little scary to me.  If, on the
other hand, we can arrange to generate these fields only when they'll
be used, that would be a lot more appealing, and obviously we might be
able to apply the same technique to the error message itself, which
would be neat, too.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Andres FreundDate: 2012-05-01 14:31:00
Subject: Re: extending relations more efficiently
Previous:From: Simon RiggsDate: 2012-05-01 14:22:49
Subject: Re: extending relations more efficiently

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group