Jonah,
What do you see as the advantages of using a VM and bytecode?
Regarding Antlr etal, are there any that generate C code. I am more
familiar with the java parsers. If we can't generate C this is
probably a non-starter.
Dave
On 28-Jun-05, at 5:58 PM, Jonah H. Harris wrote:
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 separate them from this
thread. I have a pretty sweet hand-written stack-based VM that
understands PL/SQL, but it's kinda old and written using PCCTS 1.33
(a recursive descent parser). It has compilation, decompilation,
and full debugging capabilities. Unfortunately, PCCTS is no longer
maintained as Terrence Parr (the originator) has since moved to
ANTLR. ANTLR currently does not generate C code although I have
done some starting work on it (ANTLR currently generates Python,
Java, or C++). I don't suggest we really reuse one of the current
VMs as it would require a lot more support and coordination. Let's
take the bytecode discussion off this thread and move it to
another. There is certainly a good and bad side to using bytecode
and I would be glad to discuss it in another thread.
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
Dave
On 28-Jun-05, at 10:36 AM, Pavel Stehule wrote:
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 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
[EMAIL PROTECTED])
---------------------------(end of
broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
---------------------------(end of
broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
