Thomas,
I worked on this and created some interface for decoupling java datatypes
and their representations. In my implementation the mapping is N:N, so it
is not directly applicable to your schema, but perhaps you can use some
piece of it.
I am not ready with all default data types, but the most important types
are ready.
http://cvs.plj.codehaus.org/pl-j/src/interfaces/org/pgj/typemapping/
Also, on stored procedure javadoc tags, could you take a look at this
link:
http://docs.codehaus.org/display/PLJ/Developer+tools
I am really interersted in your opinion.
Ragards,
Laszlo
On Thu, 10 Mar 2005, Thomas Hallgren wrote:
> Tom Lane wrote:
>
> >Why is PL/Java dependent on the internal representation of any
> >particular datatype? Seems like this is a symptom of bad PL design
> >more than anything else.
> >
> >
> I didn't see any other way of doing it short of using string
> conversions. That doesn't seem very optimal. Java's internal
> representation of time is millisecs so I have code in place that looks
> like this (t in this case is a TimeADT):
>
> #ifdef HAVE_INT64_Time
> mSecs = t / 1000; /* Convert to millisecs */
> if(tzAdjust)
> mSecs += Timestamp_getCurrentTimeZone() * 1000;/* Adjust from
> local time to UTC */
> #else
> if(tzAdjust)
> t += Timestamp_getCurrentTimeZone();/* Adjust from local time to
> UTC */
> t *= 1000.0; /* Convert to millisecs */
> mSecs = (jlong)floor(t);
> #endif
>
> I'm of course interested in improving it. Especially if you consider
> this bad PL design. What do you suggest I do instead?
>
> >>The dynamic loader doesn't detect this and I bet there's a ton of
> >>combinations that will link just fine but perhaps crash (badly) in
> >>runtime. I would like to detect discrepancies like this during runtime
> >>somehow. I feel that it's either that or stop providing pre-built
> >>binaries altogether. I realize that I can't be the only one with this
> >>problem. How is this normally handled?
> >>
> >>
> >
> >If you want you can look into pg_control to see how the database is
> >set up.
> >
> >
> That would cover this. Thanks (I'd still appreciate an alternative
> suggestion on the above though).
>
> Regards,
> Thomas Hallgren
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
