I'm unqualified to comment on the server side design, but I was
wondering if there was consensus on how the client interface to the
debugger would work. From previous threads I saw DBGP mentioned
(http://xdebug.org/docs-dbgp.php), but I don't recall seeing any final
commitment to it.
The patch that I'll be submitting for 8.2 will implement a way to
instrument PL/pgSQL (and that idea can be extended to other PL
languages). 'Instrumentation' can mean different things - it may be a
debugger, a profiler, a coverage analyzer, a tracer, ...
EnterpriseDB has developed a few plugins that we'll be contributing soon
(a debugger, a profiler, and a tracer). The debugger is by far the
largest plugin that we've developed and we implemented it before we had
the idea to use a modular architecture (we're still in the process of
converting the debugger to modular form, at the moment it's pretty
heavily integrated into the PL/pgSQL interpreter). As soon as we get a
patch in for the plugin architecture, we'll open-source at least one or
two of the plugins so others can use them and/or write more (the
debugger will take a little longer).
That means that we (i.e. the community) haven't made a firm commitment
to the debugger client protocol. I can tell you a little about the
protocol that we are currently using, but it may change by the time
we're ready to open-source the debugger. I gave a presentation at the
anniversary summit that described the overall architecture and also
showed the client/server protocol - the slides and audio should be
available at the conference web site "real soon now".
The most important part, from your perspective (assuming that you might
want to add a debugger to pgEdit), is the method that a debugger client
application uses to interact with the debugger server. That's done
through a collection of server-side functions that you can call from any
libpq application. For example, to set a breakpoint, you would:
SELECT * FROM pldbg_set_breakpoint( sessionHandle, functionOID,
lineNumber, processID );
to step/over:
SELECT * FROM pldbg_step_over( sessionHandle );
to step/into:
SELECT * FROM pldbg_step_into( sessionHandle );
to get a copy of all local variables:
SELECT * FROM pldbg_get_variables( sessionHandle, stackFrame );
and so on. There are a few functions that you can call to attach your
debugger client to a target server and to set global breakpoints.
I'll be posting more information as we get closer to releasing this stuff.
-- Korry
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
