Re: Implementing SQL/PSM for PG 8.2 - debugger

<br /><p><font size="2">I'm psyched for EDB to particpate and/or in some way sponsor this effort.   How can we best
helpto make this a reality sooner rather than later??<br /><br /> There's going to be a painful period later this year
whenMysqueel is able to claim that their production db has more ansi compatability than PG (at least for triggers and
storedprocs).<br /><br /> It'll be very kewl having native PG with a fully ansi-iso compliant stored procedure language
withan efficient and clean implementation with great performance charateristics and a debugger to boot...<br /><br />
--Luss<br/><br /> ------Original Message------<br /> From: Jonah H. Harris<br /> To: Dave Cramer<br /> Cc: Pavel
Stehule<br/> Cc: Tom Lane<br /> Cc: Neil Conway<br /> Cc: Jan Wieck<br /> Cc: Denis Lussier<br /> Cc:
pgsql-hackers@postgresql.org<br/> Sent: Jun 28, 2005 5:58 PM<br /> Subject: Re: [HACKERS] Implementing SQL/PSM for PG
8.2- debugger<br /><br /> Dave,<br /><br /> I lean with you and Tom.  While running it over the same libpq protocol<br
/>would be helpful in some ways, it would have a lot of drawbacks and<br /> would really change the function of libpq. 
Ithink a separate debugging<br /> protocol is in order.<br /><br /> Also, as far as bytecode comments go, let's
separatethem from this<br /> thread.  I have a pretty sweet hand-written stack-based VM that<br /> understands PL/SQL,
butit's kinda old and written using PCCTS 1.33 (a<br /> recursive descent parser).  It has compilation, decompilation,
andfull<br /> debugging capabilities.  Unfortunately, PCCTS is no longer maintained as<br /> Terrence Parr (the
originator)has since moved to ANTLR.  ANTLR<br /> currently does not generate C code although I have done some
starting<br/> work on it (ANTLR currently generates Python, Java, or C++).  I don't<br /> suggest we really reuse one
ofthe current VMs as it would require a lot<br /> more support and coordination.  Let's take the bytecode discussion
off<br/> this thread and move it to another.  There is certainly a good and bad<br /> side to using bytecode and I
wouldbe glad to discuss it in another thread.<br /><br /> Dave Cramer wrote:<br /><br /> > Pavel,<br /> ><br />
>I am in agreement with Tom here, we should use a separate port, and <br /> > protocol specifically designed for
this.<br/> ><br /> > My understanding is that this protocol would be synchronous, and be <br /> > used for
transferringstate information, variables, etc back and forth<br /> > whereas the existing protocol would still be
usedto transfer data <br /> > back<br /><br /> ------Original Message Truncated------<br /><br /><br /> --Luss<br
/><br/></font>