Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-committers(at)postgresql(dot)org" <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
Date: 2013-07-25 03:36:08
Message-ID: CAOuzzgo-_4mjW+V0rSmaR44wfG-VQANBo-oWgiL0A2DwEJVtGQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wednesday, July 24, 2013, Tom Lane wrote:

> Stephen Frost <sfrost(at)snowman(dot)net <javascript:;>> writes:
> > That said, I'll work on making this more independent of the error
> handling
> > and see if it can be made to use an independent memory context and try to
> > tighten it up to ensure it isn't called in an error case. Future callers
> > may try to.
>
> I'm not following your reasoning here. This *has* to be called in an
> error case, before you're outside the error processing context.
> Otherwise there would be no data available to be printed.

It has to be called after the context callbacks have been set up by the
levels above it on the stack (eg: SPI calls), but that's not the same as
being called from an actual exception. The idea here is to simply execute
the callbacks for each level above it on the stack and collect the strings
they create with errcontext().

In short: FlushErrorState, by definition, destroys the information that
> GetErrorContextStack looks at. So in the current implementation,
> GetErrorContextStack is burning its bridges behind it. That's at the
> very least a surprising behavior. I am betting that it will have
> unpleasant consequences for any sort of nested-error scenario.
>

Unfortunately, I don't have the code in front of me at the moment, but I
was pretty sure FlushErrorState cleans up the intermediate information set
up during an individual error call and doesn't completely clear the stack
info (tho I can't think of what, if anything, does..) or multiple "raise
notices" wouldn't each contain the stack info in their output..

I'll certainly look through this again and dream up some additional test
cases for it, in the morning.

Thanks,

Stephen

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Stephen Frost 2013-07-25 04:05:45 Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
Previous Message Tom Lane 2013-07-25 03:19:25 Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-07-25 04:05:45 Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
Previous Message Tom Lane 2013-07-25 03:19:25 Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL