Re: PL/Java issues

I'm working on a pl/java project and have come quite far with it. Triggers
and Functions are both callable, there's support for complex types etc. I
have a project on GBorg (pljava) where I'll post all source in a CVS
repository in a matter of days (the code is ready but my ISP have a router
problem preventing me from anything but slow modem contact right now).

I've glanced at the SQL standard too of course. From what I could find, it
says surprisingly little about triggers. Triggers are, IMO one place where
you very often have a natural row association (ON EACH ROW). Such triggers
would be ideal as instance methods on a type. AFAICS, there no mentioning of
that in the standard. Nor does the standard mention how the "new" and "old"
tuples can be manipulated.

At present, I map complex types to Tuple instances (a Tuple is a Java object
that has a mapping to it's native C structure correspondance, the HeapTuple
and it's associated TupleDesc) both in functions and triggers. I have a
TriggerData java class also from which you can obtain the "trigger tuple"
and the "new tuple" and I follow the postgres model of returning a modified
(or not) tuple from triggers. As this is very Postgres specific, I plan to
add a ResultSet mapping on top later on.

Another thing that surprised me with the SQL standard was that although you
can override default mapping of types on parameters in order to pass NULL
values (a primitive int can be mapped to java.lang.Integer in the parameter
list by explicitly declaring a java parameter list), there's no way to
specify the same explicit mapping of return types.

One place where the SQL standard is talking about instance mapping is when
you map specific types to Java objects. A row that in fact reflects such a
type should of course be mapped to it's respective Java object and not to an
anonymous Tuple.

Stay tuned to GBorg and pljava. I hope my ISP will fix their router problem
real soon.

- thomas

""Andrew Dunstan"" <andrew@dunslane.net> wrote in message
news:4366.24.211.141.25.1073178456.squirrel@www.dunslane.net...
> Dave Cramer said:
> > Can you explain what you mean by this?
> >
> > On Fri, 2004-01-02 at 20:21, Andrew Dunstan wrote:
> >> Will we need to address this TODO item:
> >>
> >>   . Add capability to create and call PROCEDURES
> >>
> >> before proceding to do PL/Java? It would add to the usefulness
> >> greatly,  I should think. I'm not sure how hard it would be.
> >>
>
> Well, it is syntactically unclean IMNSHO to have to define a return type
> on an SP when you don't really need one, and to have to call it by
> saying "select foo(bar)" rather than "call foo(bar)". Also, IIRC PL/SQL
> lets you bind host language variables to OUT parameters of such SPs, which
> can be quite useful. (It's a year or three since I touched Oracle in
> anger.)
>
> I would be mildly surprised if the SQL/JRT standard didn't expect to be
> able to bind to static methods of type void.
>
> (The item I quoted is on the TODO list - I didn't invent it ;-)
>
> cheers
>
> andrew
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>