On K, 2005-06-29 at 08:00 -0400, Dave Cramer wrote:
> This is an interesting suggestion, particularly the addition of
> additional connections for management
>
> However it does require all clients rewrite (yet again ) their
> connection code.
>
> My reasoning for suggesting a separate port f
This is an interesting suggestion, particularly the addition of
additional connections for management
However it does require all clients rewrite (yet again ) their
connection code.
My reasoning for suggesting a separate port for debugging are:
1) no changes to existing clients ( this prob
On K, 2005-06-29 at 10:33 +0100, Mark Cave-Ayland wrote:
> Hi guys,
>
> > I lean with you and Tom. While running it over the same libpq protocol
> > would be helpful in some ways, it would have a lot of drawbacks and
> > would really change the function of libpq. I think a separate debugging
Hi guys,
> I lean with you and Tom. While running it over the same libpq protocol
> would be helpful in some ways, it would have a lot of drawbacks and
> would really change the function of libpq. I think a separate debugging
> protocol is in order.
Just putting on my network hat for a momen
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 t
> 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 l
> I lean with you and Tom. While running it over the same libpq protocol
> would be helpful in some ways, it would have a lot of drawbacks and
> would really change the function of libpq. I think a separate debugging
> protocol is in order.
>
One message? I can't belive :).
> work on it (AN
Title: Re: [HACKERS] Implementing SQL/PSM for PG 8.2 - debugger
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 M
Dave,
I lean with you and Tom. While running it over the same libpq protocol
would be helpful in some ways, it would have a lot of drawbacks and
would really change the function of libpq. I think a separate debugging
protocol is in order.
Also, as far as bytecode comments go, let's separat
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, et
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
On Tue, 28 Jun 2005, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> 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
> > c
Pavel Stehule <[EMAIL PROTECTED]> 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 prot
>
> 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.
Pavel
Pavel,
What do you think you need for enhanced protocol ?
Dave
On 28-Jun-05, at 8:51 AM, Pavel Stehule wrote:
On Tue, 28 Jun 2005, Dave Cramer wrote:
One thing bytecode would allow us to do is to write a debugger with
break points etc.
We can write debugger with breakpoints without byte
On Tue, 28 Jun 2005, Dave Cramer wrote:
> One thing bytecode would allow us to do is to write a debugger with
> break points etc.
>
We can write debugger with breakpoints without bytecode. Every stmt rec
can have flag if has breakpoints. No problem. I don't see any advance of
bytecode. Maybe,
16 matches
Mail list logo
