Thomas Hallgren wrote:
> 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.
IMHO this is why decoupling is good and neccesary. If one configures the
RDBMS to use different another of data, then I simply replace a couple
of lines in the data mapping configuration. In the case of custom
datatypes in PostgreSQL, the same happens. This is no code modification
nor recomplitation in PL-J, only a reconfiguration.
This is why I have sent that link, but this configuration file fragment
may explain it better:
<typemapper>
<map>
<type db="timestamp"
class="org.pgj.typemapping.postgres.PGTimestamp"/>
<!-- type db="timestamp"
class="org.pgj.typemapping.postgres.PGTimestampINT64"/ -->
>
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
--
Regards,
László Hornyák
software developer