Hi,
I was just talking to Derick the author of DBGp and I realized this
might be a topic for a joint effort among all open source RDBMS. I think
it would be awesome if we could get a common protocol setup for stored
procedure debugging.
regards,
Lukas
---(end of
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: 11 June 2006 10:07
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: Proposal for debugging of server-side stored procedures
Hi Tom,
(cut)
Obviously I'm not a Perl nor Python hacker. I just
Mark Cave-Ayland wrote:
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
Thomas Hallgren wrote:
I'd use the Komodo IDE and implement the ability to start the PL using a
GUC setting per my original suggestion (with super-user requirement).
Trivial solution, minimum effort, and very useful. KISS principle.
The DBGp protocol [1] I mentioned earlier is used by Komodo
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: 09 June 2006 16:25
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: Proposal for debugging of server-side stored procedures
Some thoughts from another Tom...
Hi Tom,
Thanks for the
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 09 June 2006 17:01
To: Mark Cave-Ayland
Cc: 'Tom Lane'; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Proposal for debugging of server-side stored
procedures
(cut)
Debugging embedded perl has some
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 29 May 2006 18:05
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Proposal for debugging of server-side stored
procedures
(cut)
As far as the debug protocol details go, it'd be worth
Some thoughts from another Tom...
Mark Cave-Ayland wrote:
... debugging in Perl is initiated with perl -d somefile.pl which then
becomes a special interactive interpreter session. The same is also true
with Python which is launched in a similar way, python -m pdb somefile.py.
All PL's are
Mark Cave-Ayland wrote:
[snip]
Perl seems a little more messy in that I can't find a documented C API to
hook into the interpreter, but it looks as if it may be possible to cook
something up with writing a new DB package [2] which uses XS call a C
callback. The other issue is that unlike
Mark Cave-Ayland [EMAIL PROTECTED] writes:
The most important question to answer in my mind is how should the
debugger communicate with the server?
1) Use the existing FE/BE protocol to allow the user to control
the debugging session using stored procedures/pseudo-tables, e.g.
Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
... So basically yeah, what we need
is a debug subchannel in the FE/BE protocol. I'd suggest inventing
a single Debug message type (sendable in both directions) with the
contents being specified by a separate protocol definition. Or
Thomas Hallgren [EMAIL PROTECTED] writes:
I think this is a bad idea. PL/Java will use either shared memory or a
socket to attach and as you already mentioned, when using C, a gdb
will attach directly using the pid. I wouldn't be too surprised if
Perl, Python, and PHP all have a similar
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
I think this is a bad idea. PL/Java will use either shared memory or a
socket to attach and as you already mentioned, when using C, a gdb
will attach directly using the pid. I wouldn't be too surprised if
Perl, Python, and PHP all have a
Thomas Hallgren wrote:
Ideally, all pl's should use the same protocol. It should be language
agnostic and allow different regions of the code to origin from
different languages. That way, it would be possible to single step a
plpgsql function that in turn calls a function in pljava.
14 matches
Mail list logo
