Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL - Mailing list pgsql-committers

From Stephen Frost
Subject Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
Date
Msg-id CAOuzzgoFsPR+2J6PMVMDEpV0NA5gcvNAjhaFttD40htUCGPjBA@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL  (Stephen Frost <sfrost@snowman.net>)
List pgsql-committers
On Wednesday, July 24, 2013, Stephen Frost wrote:
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. 

Couldn't help if- reading code on a phone isn't ideal, but that's a different discussion.  

You're right- resetting the stack depth doesn't make any sense here, which FlushErrorState does.  I think clearing the memory context should be alright but that's a different story. Curious that the raise notice in the regression test didn't blow up, which is part of why I thought it was fine, but a subsequent call to raise notice in the same function would be a good test (along with another call to this function..) and I think wouldn't produce a stack trace here, which would be quite wrong. 

Will address once I'm back I front of something I can actually write code on.

Thanks,

Stephen

pgsql-committers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
Next
From: Stephen Frost
Date:
Subject: Re: pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL