Re: Runtime accepting build discrepancies

Laszlo,
> 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/
>
I can't find anything in your typemapping package that would solve this
problem. I'm faced with coercing Datum instances returned by
SPI_getbinval in the server into their Java correspondance where the
binary representation will vary depending on how PostgreSQL is compiled.

Let's assume I have a TIMETZOID as the type. I must then use the
following calls to get the time.

TimeTzADT* tza = DatumGetTimeTzADTP(arg);
TimeADT t = tza->time + tza->zone; /* Convert to UTC */

The catch is that depending on the setting of macro HAVE_INT64_TIMESTAMP
the TimeADT will be a typedef for either an int64 or a double. In case
of int64 the representation is in microsecs but if it's a double the
value is seconds (with fractions of course).

If PL/Java is compiled with a different setting of this macro, it will
think a double representing seconds is an int64 containing millisecs or
vice versa. The solution is probably to make PL/Java insensitive to this
macro and instead consult the GUC variable "integer_datetimes" and use
my own variations of TimeTzADT and TimeADT.

How do PL/J address this problem?

- thomas