Re: Implementing SQL/PSM for PG 8.2 - debugger

On Tue, 28 Jun 2005, Dave Cramer wrote:

> Pavel,
> 
> I am in agreement with Tom here, we should use a separate port, and  
> protocol specifically designed for this.
> 
> My understanding is that this protocol would be synchronous, and be  
> used for transferring state information, variables, etc back and forth
> whereas the existing protocol would still be used to transfer data  
> back and forth
> 

We can it. It can be good start point. I can do it alone. It simpler.
But I don't think so this is optimal solution. You need two protocols. 
Maybe I don't understand, but I think so changes in protocol3 files will 
be minimal. I wont to do prototype. 

Pavel

> Dave
> On 28-Jun-05, at 10:36 AM, Pavel Stehule wrote:
> 
> > On Tue, 28 Jun 2005, Tom Lane wrote:
> >
> >
> >> Pavel Stehule <stehule@kix.fsv.cvut.cz> writes:
> >>
> >>>> What do you think you need for enhanced protocol ?
> >>>>
> >>
> >>
> >>> What I need? Some like synchronous elog(NOTICE,''), which can  
> >>> return some
> >>> user's interaction, if it's possible. I didn't find how I do it with
> >>> current set of messages. But my knowleadges of protocol are minimal.
> >>>
> >>
> >> It'd probably be smarter to manage the debugging across a separate
> >> connection, so that you could carry out debugging without requiring
> >> sophisticated support for it inside the client program.  If it's
> >> single-connection then it will be essentially impractical to debug
> >> except from a few specialized clients such as pgadmin; which will
> >> make it hard to investigate behaviors that are only seen under load
> >> from a client app.
> >>
> >
> > I don't think it. Debug process halt query process in bouth variants -
> > remote | protocol. Remote debugging has one advance. I can monitor any
> > living plpgsql process, but I have to connect to some special port,  
> > and it
> > can be problem. Protocol debugging can be supported libpq, and all  
> > clients
> > libpq can debug. But is problem if PostgreSQL support bouth variants?
> >
> > btw: debuging have to be only for some users,
> >     GRANT DEBUG ON LANGUAGE plpgsql TO ..
> >
> > For me, is better variant if I can debug plpgsql code in psql console.
> > Without spec application. I don't speak so spec application don't  
> > have to
> > exists (from my view, ofcourse).
> >
> > Maybe:
> >     set debug_mode to true; -- if 't' then func stmt has src
> >     reset function myfce(integer, integer); -- need recompilation
> >     create breakpoint on myfce(integer, integer) line 1;
> >     select myfce(10,10);
> >     dbg> \l .. list current line
> >          \c .. continue
> >          \n .. next stmt
> >              \L .. show src
> >          \s .. show stack
> >          \b .. switch breakpoint
> >              \q .. quit function
> >              select myvar+10 .. any sql expression
> >          variable .. print variable
> >         \c
> >     myfce
> >         -----
> >          10
> >
> > that's all. Maybe I have big fantasy :).
> >
> > Regards
> > Pavel
> >
> > + small argument: if psql support debug mode, I don't need leave my  
> > emacs
> > postgresql mode.
> >
> >
> >
> >
> >>
> >> I don't know exactly how to cause such a connection to get set up,
> >> especially remotely.  But we should try to think of a way.
> >>
> >>             regards, tom lane
> >>
> >>
> >
> >
> > ---------------------------(end of  
> > broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to  
> > majordomo@postgresql.org)
> >
> >
>