korry.douglas wrote:
Looks great, and I'll be testing it shortly, but can I ask:
1. For 8.3 are we talking pgFoundry / contrib / core?
The server side of the debugger is implemented as a contrib module, but
not distributed with the PG core. You have to get it from pgFoundry,
untar it (which puts it into the contrib tree), then "make install"
The interview made it sound more mainstream. But then it did sound a
little disjointed too.
Do we know if it going to be distributed with pgAdmin on Windows?
2. Would you accept an additional mode: logging?
[snip self]
The debugger is implemented as an instrumentation plugin for PL/pgSQL.
As sort of a "proof-of-concept", I threw together a total of three
instrumentation plugins; the debugger, a PL/pgSQL performance profiler
(which is included in the edb-debugger tarball), and a tracer.
Don't see the tracer, unless I'm missing what you mean.
When I first read your e-mail, I thought you might be looking for the
tracer, but I see that you really want something else. Does the "RAISE
DEBUG" statement not work for you?
Problem with RAISE DEBUGs throughout my plpgsql is that it's either all
on or all off. I'd like something more controllable.
> I see you suggest recording the log
output in a table - that would be a very interesting option for the
'log_destination' GUC variable.
I'm not married to logging to a table, it just seemed sensible since the
profiler is doing that. Also, I'm not thinking of this as a way of
logging things permanently, just for debugging purposes.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
