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
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
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
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 for
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,
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
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 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 protocol
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
current set
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, 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
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
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 Mysqueel
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 (ANTLR
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
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
16 matches
Mail list logo
