>
>"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
> > And what two variants of errcontext drived by GUC? First current
> > (compatible) and second enhanced (with oid, params, maybe all possible
>debug
> > values) and possible machine's readable. This enhanced variant can be
> > compatible and shared in all environments.
>
>[ shrug... ] The complaints I've heard about the errcontext mechanism
>are that it's too verbose already. I can't see a good use-case for the
>above, and I do know that a lot of people wouldn't consider it an
>"enhancement" at all.
>
>I suspect the problems you wish to solve would be better addressed by
>using the plpgsql debugger that will be available with 8.2. It sounds
>to me like you are wishing for a debugger stack trace, and if you need
>one of those you probably need other debugger facilities too.
>
plpgsql debugger's plugin can be solution. But it's big gun for me and has
little bit overhead. We have really large plpgsql library, where we very
often use overloading of functions, and I finding way for usefull error
handling, and I need collect all possible information about stack track.
Current format of stack track isn't really usefull. Only name, line and
statement are less. With func oid I can get all other info later, without
it, I need estimate which functions are in stack track. By example, for me
aren't important language, in 99% is plpgsql.
I wouldn't use debugger in production datatabase.
Pavel Stehule
_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/
