Runtime accepting build discrepancies

Thomas Hallgren <thhal@mailblocks.com> writes:

A user download a pre-built PostgreSQL 7.4.7 from somewhere and a
pre-built pljava distro from gborg. He gets everything running but
suddenly encounteres problems with the timetz type. PL/Java apparently
return the time as zero. The problem is caused by the postgresql binary
being built using --enable-integer-datetimes whereas the PL/Java binary
is not.

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.

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.

regards, tom lane

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

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:

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

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

Laszlo Hornyak wrote:

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"/ -->

Sure Laszlo. That solves everything. But where do you get the
information on what to comment out and what to use in the first place?

Regards,
Thomas Hallgren

The default should be the default used by PostgreSQL, and the extra ones
should be commented out under it.
Not the most user friendly solution, but can we do anything else?

Laszlo

On Fri, 11 Mar 2005, Thomas Hallgren wrote:

Laszlo Hornyak wrote:

The default should be the default used by PostgreSQL, and the extra ones
should be commented out under it.
Not the most user friendly solution, but can we do anything else?

Yes, we can do as I suggested and select mapping depending on the GUC
variable "integer_datetimes". I guess you have some initial handshake
between the postgresql backend and the JVM where you can negotiate
things like that?

Regards,
Thomas Hallgren