Hi, Thomas,
Thomas Hallgren schrieb:
> bytea is mapped to byte[]. The other types are not yet mapped. Where can
> I find info about the PostGIS approach?
The best is to look at the class org.postgresql.util.PGobject in the
pgjdbc source, and the classes derived from it (spitted over multiple
packages). I do not know whether there actually is any additional
documentation around.
PostGIS simply uses PGConnection.addDatataType() to add additional
mappings for their datatypes, it is all documented in the PostGIS
source, jdbc2 subdirectory. (Best to use a CVS checkout from
www.PostGIS.org).
The PGobject approach currently suffers from at least three
deficiencies, which were discussed here and at various other places:
- Some problems with null values (AFAIR, not really shure about).
- Can only use canonical text representation, no binary rep yet.
- There is a fixed 1:1 mapping between PostgreSQL types and java
classes. This causes problems as all PostGIS geometry types are modeled
as PostgreSQL "geometry" type, but different classes (polygon, point,
linestring) in java. Thus, the PGobject subclass PGgeometry currently is
merely a wrapper around the real geometry classes.
In my eyes, the best solution would be a factory instance based
approach. The factory knows how to serialize and deserialize several
java classes that all map to the same PostgreSQL java type.
>> And what is your approach to endianness conversion?
>>
> None yet. What types have endian issues and in what way? The PLJava
> mapping is using SPI functions directly so we never serialize anything.
> PLJava create wrappers for Datum's in the native backend environment.
> I'm not sure endian issues ever bites us.
Well, I do not know anything about SPI yet, but it just got on my todo list.
For complex datatypes, if you use the internal representation for your
java mapping, you have to parse bytes, 32-bit integers, doubles and such
from the in-memory representation. This depends on the machine
endianness. Alternatively, you can use the canonical representations
(using the types INPUT/OUTPUT/SEND/RECEIVE functions), but this incurs
additional overhead.
Is there any documentation about such PLJava internals?
Markus
--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios@logi-track.com | www.logi-track.com
