Re: Runtime accepting build discrepancies
От | Thomas Hallgren |
---|---|
Тема | Re: Runtime accepting build discrepancies |
Дата | |
Msg-id | 422F80B1.8080108@mailblocks.com обсуждение исходный текст |
Ответ на | Re: Runtime accepting build discrepancies (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Runtime accepting build discrepancies
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: