Tom Lane wrote:
> Thomas Hallgren <thomas@tada.se> writes:
>
>> Tom Lane wrote:
>>
>>> In particular, it seems unsafe to use a Java class as a PG UDT,
>>> because the method pointers wouldn't remain the same across
>>> backend runs.
>>>
>>>
>> I'm not sure I understand what you mean.
>>
>
> Doesn't a Java object contain a method-table pointer that is used at
> runtime to dispatch method calls on the object? If the object is dumped
> bitwise into a PG table, and then reloaded into another backend session
> (which maybe has loaded Java at different addresses), that pointer will
> be invalid.
>
Ah, now I understand. I'm not planning on using the binary image of the
Java object as such. There's no API that would allow me to do that (JNI
uses handles, not pointers).
Java has a number of standards for how objects can be
serialized/deserialized in a safe, JVM independent way. If the class of
the object is known at all times (as it will be for all UDT's), I can
use a DataInputStream/DataOutputStream pair to read/write data. It's
very similar to how the complex example type uses pg_sendxxx and
pg_getmsgxxx functions. The Java implementation of that example will
also use 16 bytes for storage.
More complex types can use the standard Java serialization mechanism. It
will waste some more space (must be declared variable in length) but it
maintains data integrity over time through serialVersionUUID's (a 64 bit
number generated based on the constitution of the class).
JDBC defines a standard that involves usage of three different
interfaces, SQLData, SQLInput, and SQLOutput. I plan to support that also.
Kind Regards,
Thomas Hallgren