FAQ

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, goto stmt is possible.

What is problem? We need synchronous comunication (message) between
backend frontend.

I have idea (in exec_stmt()

CHECK_FOR_INTERRUPTS();
if (stmt->breakpoints)
estate->debug_mode = true;
if (estate->debug_mode)
{
for (;;)
{
rc = request_command();
switch (rc)
{
case 'c': -- continue
estate->debug_mode = false;
break
case 'q':
elog(EXCEPTION, "stop debug");
break;
case 'n':
break;
case 'l':
sendstring(line(estate->src,
stmt->lineno));

Please, can somebody help me with protocol enhancing? It is mayor work on
PL/pgSQL debugger (and plperl and plpython too).

Using a java jvm however is considerable overkill.

Dave
On 27-Jun-05, at 8:28 PM, Neil Conway wrote:

Jonah H. Harris wrote:
I don't recommend discussion for this in this thread, but it could
also tie in with the packages support we've discussed and
(although some may argue this), compiling the PL to bytecode and
using that.
How would compilation to bytecode help?

-Neil

---------------------------(end of
broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Search Discussions

  • Dave Cramer at Jun 28, 2005 at 1:00 pm
    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 bytecode. Every stmt
    rec
    can have flag if has breakpoints. No problem. I don't see any
    advance of
    bytecode. Maybe, goto stmt is possible.

    What is problem? We need synchronous comunication (message) between
    backend frontend.

    I have idea (in exec_stmt()

    CHECK_FOR_INTERRUPTS();
    if (stmt->breakpoints)
    estate->debug_mode = true;
    if (estate->debug_mode)
    {
    for (;;)
    {
    rc = request_command();
    switch (rc)
    {
    case 'c': -- continue
    estate->debug_mode = false;
    break
    case 'q':
    elog(EXCEPTION, "stop debug");
    break;
    case 'n':
    break;
    case 'l':
    sendstring(line(estate->src,
    stmt->lineno));

    Please, can somebody help me with protocol enhancing? It is mayor
    work on
    PL/pgSQL debugger (and plperl and plpython too).


    Using a java jvm however is considerable overkill.

    Dave
    On 27-Jun-05, at 8:28 PM, Neil Conway wrote:

    Jonah H. Harris wrote:

    I don't recommend discussion for this in this thread, but it could
    also tie in with the packages support we've discussed and
    (although some may argue this), compiling the PL to bytecode and
    using that.
    How would compilation to bytecode help?

    -Neil

    ---------------------------(end of
    broadcast)---------------------------
    TIP 5: Have you checked our extensive FAQ?

    http://www.postgresql.org/docs/faq

  • Pavel Stehule at Jun 28, 2005 at 1:19 pm
    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
  • Tom Lane at Jun 28, 2005 at 1:51 pm

    Pavel Stehule 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 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
  • Pavel Stehule at Jun 28, 2005 at 2:43 pm

    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
  • Dave Cramer at Jun 28, 2005 at 4:55 pm
    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 <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)
  • Pavel Stehule at Jun 28, 2005 at 9:13 pm

    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)
  • Jonah H. Harris at Jun 28, 2005 at 9:59 pm
    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 <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)

    ---------------------------(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
  • Pavel Stehule at Jun 28, 2005 at 10:34 pm

    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 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.
    I see only one advantage of WM - sharing between languages. But SQL/PSM or
    PL/pgSQL are not clasic languages. Big advantage is big disadvantage too
    -> relation on SQL engine. I can use all SQL types, but I can't to do
    efective concation of strings. Sorry, I don't see any benefit of bytecode
    for these languages.

    PL/pgSQL works fine (for specific task). What can be better?

    o evaluation of expressions. -- needs integration with sql parser
    o debugging
    o persistent compiled code
    o syntax

    Please, write me, private, your opinions. And don't scowl at me, so I am
    in oportunity :).

    Regards
    Pavek
  • Dave Cramer at Jun 29, 2005 at 12:04 pm
    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 <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)


    ---------------------------(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
  • Jonah H. Harris at Jun 29, 2005 at 4:40 pm
    Hey Dave,

    I see a few of the advantages and disadvantages as follows:

    ADVANTAGES
    - Faster execution (a single parse/compile)
    - The ability for companies/people to write PL code and not directly
    share the source (though disassembly is always possible)
    - Built-in debugging support (could be added to something like PL/pgSQL,
    but would work better if built into the system from the ground-up)
    - Support for PL profiling (great for some of the newbie PL writers and
    would be useful for finding performance problems when packages come around)
    - Better/faster exception handling

    DISADVANTAGES
    - Generated bytecode would have to be platform independent
    - Maintenance of the VM itself (how many people would be able to pick up
    development/support)
    - Platform support for the VM (not really that big of an issue if it's
    done right)

    I have experience writing both stack and register based VMs but I
    believe that a stack-based VM would be a great way to implement PLs.
    Sure, a register-based VM sometimes runs faster than a stack-based
    machine, but it is also a great deal more complex.

    Just a couple thoughts :)

    -Jonah

    Dave Cramer wrote:
    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 <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)


    ---------------------------(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
  • Denis Lussier at Jun 28, 2005 at 10:28 pm
    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 production db has more ansi compatability than PG (at least for triggers and stored procs).

    It'll be very kewl having native PG with a fully ansi-iso compliant stored procedure language with an efficient and clean implementation with great performance charateristics and a debugger to boot...

    --Luss

    ------Original Message------
    From: Jonah H. Harris
    To: Dave Cramer
    Cc: Pavel Stehule
    Cc: Tom Lane
    Cc: Neil Conway
    Cc: Jan Wieck
    Cc: Denis Lussier
    Cc: pgsql-hackers@postgresql.org
    Sent: Jun 28, 2005 5:58 PM
    Subject: Re: [HACKERS] Implementing SQL/PSM for PG 8.2 - debugger

    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
    ------Original Message Truncated------


    --Luss
  • Pavel Stehule at Jun 28, 2005 at 10:53 pm
    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 language isn't essentials. Possiblity run
    perl or python prucedures is important. Today is first day of discussion
    and there is half of year space for developing.
    It'll be very kewl having native PG with a fully ansi-iso compliant
    stored procedure language with an efficient and clean implementation
    with great performance charateristics and a debugger to boot...
    >

    Who not?
  • Robert Treat at Jun 29, 2005 at 4:28 am

    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 production db has more ansi compatability than PG (at
    least for triggers and stored procs).
    Have you seen thier trigger implementation? It's about on par with pg's left
    join capabilities around 7.0.

    --
    Robert Treat
    Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
  • Mark Cave-Ayland at Jun 29, 2005 at 9:34 am
    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 moment... Would an approach be to come
    up with a generic encapsulation protocol, similar in principle to PPP, in
    which we could run any protocols we wanted?

    If we had something like a PGSQL Encapsulation Protocol (PGEP) used to
    transfer all data between a PostgreSQL client/server, then we can use this
    to tunnel libpq requests as they are at the moment through to the other
    side. However, it would also mean that people could add any other protocols
    as they see fit for debugging, statistics and all sorts of things that
    people have yet to think of.

    Obviously this would require a client/server interface change so it's not to
    be taken lightly, but I thought I'd mention it since people have mentioned
    the possibility of changes to the FE/BE protocol.


    Kind regards,

    Mark.

    ------------------------
    WebBased Ltd
    17 Research Way
    Tamar Science Park
    Plymouth
    PL6 8BT

    T: +44 (0)1752 797131
    F: +44 (0)1752 791023
    W: http://www.webbased.co.uk
  • Hannu Krosing at Jun 29, 2005 at 10:07 am

    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
    protocol is in order.
    Just putting on my network hat for a moment... Would an approach be to come
    up with a generic encapsulation protocol, similar in principle to PPP, in
    which we could run any protocols we wanted?
    That's what I also thought, but was too busy/lazy to write up :)
    If we had something like a PGSQL Encapsulation Protocol (PGEP) used to
    transfer all data between a PostgreSQL client/server, then we can use this
    to tunnel libpq requests as they are at the moment through to the other
    side.
    also, additional channels un PGEP could be initiated in both directions,
    and things like NOTIFY could be put in a different channel.
    However, it would also mean that people could add any other protocols
    as they see fit for debugging, statistics and all sorts of things that
    people have yet to think of.
    One example would be connection keepalive protocol , run over its own
    channel in PGEP and used in case TCP link has a tendency to fail.

    This should be run from server to client during idle periods, just to
    see if client is still there.
    Obviously this would require a client/server interface change so it's not to
    be taken lightly, but I thought I'd mention it since people have mentioned
    the possibility of changes to the FE/BE protocol.
    As protocol is negotiated at startup anyway, this is a change that could
    be done in a backward compatible manner .

    --
    Hannu Krosing <hannu@skype.net>
  • Dave Cramer at Jun 29, 2005 at 12:00 pm
    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 probably could be done by
    extending the existing protocol )

    2) Ability to run your existing applications, not just psql, but any
    application and remotely debug without interfering
    with the current connection data.

    3) Relatively easy to create (name your favorite language) debuggers

    4) Seems easier to connect, and disconnect from the process of interest.


    Dave
    On 29-Jun-05, at 6:06 AM, Hannu Krosing wrote:
    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
    protocol is in order.
    Just putting on my network hat for a moment... Would an approach
    be to come
    up with a generic encapsulation protocol, similar in principle to
    PPP, in
    which we could run any protocols we wanted?
    That's what I also thought, but was too busy/lazy to write up :)

    If we had something like a PGSQL Encapsulation Protocol (PGEP)
    used to
    transfer all data between a PostgreSQL client/server, then we can
    use this
    to tunnel libpq requests as they are at the moment through to the
    other
    side.
    also, additional channels un PGEP could be initiated in both
    directions,
    and things like NOTIFY could be put in a different channel.

    However, it would also mean that people could add any other protocols
    as they see fit for debugging, statistics and all sorts of things
    that
    people have yet to think of.
    One example would be connection keepalive protocol , run over its own
    channel in PGEP and used in case TCP link has a tendency to fail.

    This should be run from server to client during idle periods, just to
    see if client is still there.

    Obviously this would require a client/server interface change so
    it's not to
    be taken lightly, but I thought I'd mention it since people have
    mentioned
    the possibility of changes to the FE/BE protocol.
    As protocol is negotiated at startup anyway, this is a change that
    could
    be done in a backward compatible manner .

    --
    Hannu Krosing <hannu@skype.net>

  • Hannu Krosing at Jun 29, 2005 at 12:17 pm

    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 debugging are:
    I'm not objecting to the idea of a separate "port", just suggesting one
    way to connect to that port using clients that are aware of the new PGEP
    protocol.

    the old ones can continue to work as they are.

    --
    Hannu Krosing <hannu@skype.net>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 28, '05 at 12:51p
activeJun 29, '05 at 4:40p
posts18
users8
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase