Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> If you want I'll draft something up.
> I'll take care of it, thanks for the idea!
OK. One possibly non-obvious point is that I think the field should be
defined as "context containing associated non-constant strings"; this
would
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> [...] a better idea is to add a memory-context-to-use field to struct
> ErrorData. We'd initialize it to ErrorContext when pushing a stack
> entry for normal error processing, but GetErrorContextStack could
> do something different. This would eliminate mo
2013/7/25 Stephen Frost :
> Pavel,
>
> First, please only quote the relevant parts of the email when
> responding.
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I used a ErrorContext because I wasn't sure so errcontext and similar
>> function can work in different context. Now I look ther
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> 1. Just run the whole business in the caller's context and leave it up
>> to the caller to worry about whether it needs to clean up memory usage.
> I'd certainly be fine with that, and had considered it, but it looks
> like errcont
Pavel,
First, please only quote the relevant parts of the email when
responding.
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I used a ErrorContext because I wasn't sure so errcontext and similar
> function can work in different context. Now I look there and there
> should be well initializ
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> 1. Just run the whole business in the caller's context and leave it up
> to the caller to worry about whether it needs to clean up memory usage.
I'd certainly be fine with that, and had considered it, but it looks
like errcontext_msg() (which is called by t
Hello
2013/7/25 Tom Lane :
> Stephen Frost writes:
>> I've just pushed up some much needed improvements to the comments which
>> hopefully clarify that this function is using error_context_stack and
>> calling the callbacks set up there by callers above on the PG call
>> stack.
>
> Now that I'm a
Stephen Frost writes:
> I've just pushed up some much needed improvements to the comments which
> hopefully clarify that this function is using error_context_stack and
> calling the callbacks set up there by callers above on the PG call
> stack.
Now that I'm a bit more awake, I realize that my co
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> 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.
>
> In short: FlushErrorState, by definition, destroys
On Thursday, July 25, 2013, Stephen Frost wrote:
> 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
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
On Wednesday, July 24, 2013, Tom Lane wrote:
> Stephen Frost > 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. Futur
Stephen Frost 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
On Wednesday, July 24, 2013, Stephen Frost wrote:
> Still, if there's a reasonable way to collect the stack info without going
> through the error callbacks, without implementing a duplicate system, I'm
> all ears.
>
That said, I'll work on making this more independent of the error handling
and s
Stephen Frost writes:
> On Wednesday, July 24, 2013, Tom Lane wrote:
>> I don't find it to be a terribly good idea that GetErrorContextStack
>> does FlushErrorState().
> It's not intended (nor allowed, if I got it right) in an error context. I
> will admit that it's not a wonderful situation to h
Tom,
On Wednesday, July 24, 2013, Tom Lane wrote:
> Stephen Frost > writes:
> > Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
>
> I don't find it to be a terribly good idea that GetErrorContextStack
> does FlushErrorState(). Doesn't that imply that it can't safely be
> used from inside error pr
Stephen Frost writes:
> Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
I don't find it to be a terribly good idea that GetErrorContextStack
does FlushErrorState(). Doesn't that imply that it can't safely be
used from inside error processing, which is more or less exactly
where it is intended to
Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
This adds the ability to get the call stack as a string from within a
PL/PgSQL function, which can be handy for logging to a table, or to
include in a useful message to an end-user.
Pavel Stehule, reviewed by Rushabh Lathia and rather heavily whacked
18 matches
Mail list logo
