plpgsql debugger (experimental) (fwd)

Hello

I can't to send this mail to pghackers. I don't know reason, it's
unimportant. Next some months I can't to continue in my less work for
postgres. Maybe can be usefull and inspiration for somebody.

Attachments contains patch for debugger (tracer) plpgsql and sample
session. This patch is really hack, but contains all what need, and I hope
will be usefull for next work and discussion. For apply to main tree needs
much better data structures (breakpoints), UI, commands, ...

I plan to add:
quite tracing
better trace info: last n stmts
showing stack
variable value's watchdogs (lt, gt, eq constant,change)

The base of patch is adding two new messages into protoco3. 't' backend
request for user response, 'T' user's response.

Debuger can 's' step, 'p' print, 'c' continue, 'l' list, 'q' quit
commands, please see debug_session file.

Debugger is easy, and has minimal funkcionality, but don't need
bigger changes in plpgsql code (I am not able to do :-().

o it can show all variables, but isn't possible detect current
variable's scope (namespace stack don't exist in runtime)
o isn't possible evaluation of expression (problem with namespace stack
and parsing expression is possible only with compiler time now.
o isn't possible show any system information's now

There was discussion about remote or protocol based dbg<->frontend
comunication

Protocol based
==============
+ is easy, minimal impact on older application
+ every new application can support debugging
(handler traceProcessor)
+ all interfaces based on psql has debug. support
(emacs modes, atd)
+ none problem with debugging in one thread application (psql)
+ none problem with security or minimal
(on production's system debugging can hold resources)
- zero possibility debug older application

Remote debug
============
+ none impact on older application
+ possibility debug older application
+ better for multi threaded app
- needs solving security problem's (more code)
more complicated than sending cancel commnd
security key isn't possible

I hope PostgreSQL will support both variants in future.

I invite any notes, suggestions

Regards
Pavel Stehule