Pavel Stehule escribió:
> 2009/7/13 Alvaro Herrera :
> > Pavel Stehule escribió:
> >> Hello
> >>
> >> I did some similar (but Oracle like) in orafce - so it can help. I
> >> thing, so this should be very useful, but result set isn't best
> >> format. Usually you would to print to log and you have t
On Mon, Jul 13, 2009 at 4:00 PM, A.M. wrote:
>
> How would I go about generating a meaningful backtrace for a plpgsql
> function that calls a plperl function? One would also expect a C function
> which calls a plpgsql function to appear, too, no? Shouldn't there be a
> unified backtrace subsystem?
On Jul 13, 2009, at 4:51 PM, decibel wrote:
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
Alvaro Herrera writes:
Tom Lane wrote:
The performance and error recovery implications are unfavorable.
Just how badly do you need this, and for what?
Mainly for debugging. The situation is such tha
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
Alvaro Herrera writes:
Tom Lane wrote:
The performance and error recovery implications are unfavorable.
Just how badly do you need this, and for what?
Mainly for debugging. The situation is such that there is a lot of
functions and very high loa
Alvaro Herrera wrote:
> This is a preliminary request for comments on obtaining a function call
> stack. I've been trying to dodge the issue by exporting elog.c internal
> state (errcontext), but that turns out to be unfeasible and it's such a
> horrid kludge anyway.
>
> So, the idea is to have a
2009/7/13 Alvaro Herrera :
> Pavel Stehule escribió:
>> Hello
>>
>> I did some similar (but Oracle like) in orafce - so it can help. I
>> thing, so this should be very useful, but result set isn't best
>> format. Usually you would to print to log and you have to iterate via
>> set. So maybe better
Alvaro Herrera writes:
> Tom Lane wrote:
>> The performance and error recovery implications are unfavorable.
>> Just how badly do you need this, and for what?
> Mainly for debugging. The situation is such that there is a lot of
> functions and very high load. The functions have embedded "debug
On Jul 13, 2009, at 2:02 PM, Tom Lane wrote:
Alvaro Herrera writes:
So, the idea is to have a stack maintained by the function
manager; each
called function enters an element in it containing the interesting
information about the function. We'd have another function that
would
return this
Pavel Stehule escribió:
> Hello
>
> I did some similar (but Oracle like) in orafce - so it can help. I
> thing, so this should be very useful, but result set isn't best
> format. Usually you would to print to log and you have to iterate via
> set. So maybe better format could be some structured te
Tom Lane wrote:
> Alvaro Herrera writes:
> > So, the idea is to have a stack maintained by the function manager; each
> > called function enters an element in it containing the interesting
> > information about the function. We'd have another function that would
> > return this stack as a result
Hello
I did some similar (but Oracle like) in orafce - so it can help. I
thing, so this should be very useful, but result set isn't best
format. Usually you would to print to log and you have to iterate via
set. So maybe better format could be some structured text.
regards
Pavel Stehule
2009/7/1
Alvaro Herrera writes:
> So, the idea is to have a stack maintained by the function manager; each
> called function enters an element in it containing the interesting
> information about the function. We'd have another function that would
> return this stack as a result set. (With this arrangeme
Hi,
This is a preliminary request for comments on obtaining a function call
stack. I've been trying to dodge the issue by exporting elog.c internal
state (errcontext), but that turns out to be unfeasible and it's such a
horrid kludge anyway.
So, the idea is to have a stack maintained by the func
13 matches
Mail list logo
