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 [EMAIL PROTECTED] > ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly