Re: Loading the PL/pgSQL debugger (and other plugins)

Hi korry-san.

From: "korry"

>
> > 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, ...

I can regard it as very great. probably, It is expected that workstation
(edb-debugger) is realizable with an addition of some language parser.:-)

>
> 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".

Great.!
Your session was very wonderful. People who were not able to hear it will be seen.

>
> 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.

This regards me as a very great contribution.!
As for me, the feeling of workstation (edb-debugger) was pleased very much.
I consider it so that often to pgAdmin. Then, I am looking forward to the evolution.:-)

Thanks!!

Regards,
Hiroshi Saito