Re: TODO list: Allow Java server-side programming
От | Peter Eisentraut |
---|---|
Тема | Re: TODO list: Allow Java server-side programming |
Дата | |
Msg-id | Pine.LNX.4.30.0102031746220.8648-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: TODO list: Allow Java server-side programming (Peter Mount <peter@retep.org.uk>) |
Ответы |
Re: TODO list: Allow Java server-side programming
|
Список | pgsql-hackers |
Peter Mount writes: > Thats correct. Basically you are talking of something like PL/Java. The > Java side would be simple, but its linking the JVM to the backend that's > the problem. I've tried that recently, here's how it looks as far as Linux JVMs go: * Kaffe has a very polluted name space. Calls to its own functions get resolved to PostgreSQL, and vice versa. Crash and burn result. The Kaffe folks have admitted that this should be fixed but I didn't look farther yet. * The Sun/Blackdown JVM didn't work at all (not even 'java -version') until I upgraded my libc. Then a simple test run crashes with an "error external to JVM"; at first it looked like a segfault when referencing a string constant. In gdb I saw myself faced with about 10 threads running when nothing was going on yet, at which point I was too exhausted to proceed. * IBM's offering didn't work at all. I don't recall the problem anymore but I think it didn't even link correctly. So currently I don't see how this could become a mainstream project, let alone across platforms. > I know some people think this would slow the backend down, but it's only > the instanciation of the JVM thats slow, hence the other reason fork() is > holding this back. Ideally you would want the JVM to be running with > PostMaster, and then each backend can then use the JVM as and when necessary. But how do the other languages cope? Starting up a new Perl for each backend can't be so cheap either. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: