Re: Proposal for debugging of server-side stored procedures

> -----Original Message-----
> From: Thomas Hallgren [mailto:thomas(at)tada(dot)se]
> Sent: 09 June 2006 16:25
> To: Mark Cave-Ayland
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: Proposal for debugging of server-side stored procedures
>
> Some thoughts from another Tom...

Hi Tom,

Thanks for the feedback :)

> All PL's are launched someway or another . It would probably be very
> simple to add the '-d'
> flag to the PL/Perl launcher and the '-m' flag to the PL/Python launcher
> and control it with
> module specific GUC settings. PL/Java already does this. The SQL to
> initialize debugging
> looks like this:
>
> SET pljava.vmoptions TO '-
> agentlib:jdwp=transport=dt_shmem,server=y,suspend=y';
>
> This tells the VM to load in-process debugging libraries and specifies the
> kind of
> connection to be made. As soon as the first java function is called, the
> process is
> suspended and waits for a client debugger to attach.
>
> The amount of work needed to create similar solutions for perl, python,
> tcl, etc. is
> probably limited and fairly trivial.

I think that Java is quite unusual in that the design of JPDA is inherently
client/server based to the point where they have defined the platform to
allow you interact with the JVM via a socket. Unfortunately the same can't
be said for Perl/Python - as you suggest passing the parameters into the
interpreter is a trivial exercise but because the debugging classes in both
languages are console interactive, the only thing you could do is redirect
the console output to a socket (see
http://search.cpan.org/dist/perl/lib/perl5db.pl and the RemotePort option in
the case of Perl).

What I would like to see is some form of IDE that our developers can use,
probably under Windows, that would enable them to step through and debug
stored procedures on a remote server on another network. Using simple
console redirection would involve parsing text output which strikes as being
something that would break easily with new releases.

And then of course, there is the problem of security whereby anyone could
connect to the socket. For example, imagine a group of developers all
debugging different functions simultaneously; if one of them connected to
the wrong console socket then it could be confusing as the developer wanders
why their code never stops at a breakpoint.

> And it would force you to write your own proprietary debugger backend for
> each language.
> That's a major thing to undertake. Have you considered the maintenance
> aspect of it? Not
> something that would make the author of a PL module scream with joy. It
> might be wise to
> also consider what debugger preferences a skilled perl/python/<whatever
> language> developer
> might have. A home brewed debugger in the form of a PostgreSQL add-on
> might not be a natural
> choice.

Well my original thinking was that you could factor most of the code into
PostgreSQL itself; the only thing that PL developers would have to is
provide an API for things like step, set breakpoint, read variable, and
eval.

A promising option at the moment would be to implement the DBGP protocol for
Perl/Python/Tcl as suggested by Lukas, mainly because it appears ActiveState
have already written the modules to do this (see
http://aspn.activestate.com/ASPN/Downloads/Komodo/RemoteDebugging) The only
issue I can see with this is again related to security in that the debugger
would not respect the ACLs within PostgreSQL which could potentially allow a
user to break inside a function that wasn't his/her own.

Kind regards,

Mark.

------------------------
WebBased Ltd
17 Research Way
Plymouth
PL6 8BT

T: +44 (0)1752 797131
F: +44 (0)1752 791023

http://www.webbased.co.uk
http://www.infomapper.com
http://www.swtc.co.uk

This email and any attachments are confidential to the intended recipient
and may also be privileged. If you are not the intended recipient please
delete it from your system and notify the sender. You should not copy it or
use it for any purpose nor disclose or distribute its contents to any other
person.