Re: Loading the PL/pgSQL debugger (and other plugins) - Mailing list pgsql-hackers

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