Holger Krug <hkrug@rationalizer.com> writes:
> As you probably know, you are not the first attempting to allow java
> classes as stored procs. I'm interested in why you people are
> attempting this. I can imagine 2 goals, the one of which is a hot
> issue also for me and should has a relative simple solution, the other
> seems to be not very imported and heavy to achieve:
>
> 1. goal) Give PostgreSQL after triggers the ability to notify Java
> apps about events in the database. In almost all cases this
> would be done using a JMS (Java Message Service) implementation
> in an application server which has to be called by the after
> trigger.
> 2. goal) To have Java as a YAPL4P (yet another procedural language for
> PostgresSQL).
>
> I think all the big problems regularly reported on this list when a
> new attempt is announced to be made to create a java plugin for
> PostgreSQL are related to the second point: Java as a full-scale
> YAPL4P - which is nice but should not be very important.
>
> But if you have the same goal as I would like to have to time for:
> using Java to notify outside Java apps about database events, then - I
> think - your approach is promising and I wish you really good luck.
Actually my initial goal is neither of these things. My initial goal
is to learn about the internals of pg.
I am more of a Java programmer than a C programmer (just because I'm
lazy) and therefore I would like to pursue your second option.
The most difficult part of that is actually defining the java function
interface, but other than that I think I've already cracked it (I
wrote most of the JDBC implementation last night).
As for your 1st objective... I don't think that would be easy, even
with what I'm proposing there would have to be some sort of RMI or
CORBA link to the remote app.
Nic
