Joe,
I think at least initially things can be a lot simpler:
Joe Shevland wrote:
>
> * Using tools.jar to parse and compile the function source code
I would suggest that we just follow the lead of C functions. The
database doesn't compile your C source when you register a C function,
you just tell the database where the precompiled code is and what the
entry point is. To start with, I think the java version should do the
same. Tell the server the statuc class.method to run, but leave the
compiling and loading the classes to the user.
> * One JVM per PostgreSQL server (configurable via postgresql.conf)
Yes.
> * One classloader per database to keep things clean and separate
Sure.
> * JSP-like compilation - functions compiled when there is a change in the code, or first created. Otherwise remains
memoryresident as a class instance, and/or is created on server startup.
Overkill (at least initially) see my comments above.
> * Communication would be via JNI (Java<->C): the JVM would be assumed to be resident on the same server... unless
we'dwant to look at load balancing, again I keep thinking of the boundaries of what the db should do.
Should reuse the FE/BE protocol, and then much of the work is done in
the existing jdbc driver code
> * Mapping between Java and PG types handled by a central thing
Already handled by the existing FE/BE code in both jdbc and the server.
>
> Wading further and further into deep water here I think,
>
> Cheers,
> Joe
>
thanks,
--Barry
