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