Thread: Re: Implementing SQL/PSM for PG 8.2 - debugger

Re: Implementing SQL/PSM for PG 8.2 - debugger

From
"Denis Lussier"
Date:
<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> 

Re: Implementing SQL/PSM for PG 8.2 - debugger

From
Pavel Stehule
Date:
> There's going to be a painful period later this year when Mysqueel 
is able to claim that their production db has more ansi compatability 
than PG (at least for triggers and stored procs).

MySQL5 is really comparable with Pg8, but Firebird2 or SQLlite3 too. But 
from my perspective procedural language isn't essentials. Possiblity run 
perl or python prucedures is important. Today is first day of discussion 
and there is half of year space for developing. 

> 
> It'll be very kewl having native PG with a fully ansi-iso compliant 
stored procedure language with an efficient and clean implementation 
with great performance charateristics and a debugger to boot...
> 

Who not?




Re: Implementing SQL/PSM for PG 8.2 - debugger

From
Robert Treat
Date:
On Tuesday 28 June 2005 18:29, Denis Lussier wrote:
> I'm psyched for EDB to particpate and/or in some way sponsor this effort.  
> How can we best help to make this a reality sooner rather than later??
>
> There's going to be a painful period later this year when Mysqueel is able
> to claim that their production db has more ansi compatability than PG (at
> least for triggers and stored procs).
>

Have you seen thier trigger implementation?  It's about on par with pg's left 
join capabilities around 7.0. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL