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(at)kix(dot)fsv(dot)cvut(dot)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(at)postgresql(dot)org)
> >
> >
>