Bytecode and virtual machine

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(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)
>>>
>>>
>>>
>>
>>
>> ---------------------------(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
>
>