Bytecode and virtual machine - Mailing list pgsql-hackers

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