[postgis-users] different results from PGobject.getValue()

Markus Schaber schabi at logix-tt.com
Tue Feb 13 10:00:57 PST 2007


Hi, Claude,

"Claude Eisenhut" <ce at eisenhutinformatik.ch> wrote:

> > Btw, we might drop PostGIS 0.X support eventually, or change the
> > autoregistration to use the PGgeometrylw class, what do you think about
> > that?
> 
> I would prefer if different libraries could work with the same connection
> without interference.

They can, as PGgeometry only registers for the PostGIS geometry
datatypes, other datatypes are not affected, and explicit registration
of datatype handlers via Connection.addDataType() always overrides
autoregistration.

Btw, did you notice that some builtin datatypes like PGbytea, PGmoney
and PGInterval use the same mechanism, subclassing the PGgeometry
class? That's what PGobject is meant for, being subclassed by driver
extensions. It's only a "soft fallback solution" that a plain PGobject
is returned instead of failing with an unknown datatype exception when
a datatype extension is missing.

> And I would prefer if the JDBC driver offers a stable (hiding server
> versions), but as fast as possible (raw/low level) interface.

The problem is that the server sends and receives different
representations, depending on which PostGIS version is installed.

The PGgeometry class is exactly that part of the driver that is meant
to hide server (PostgreSQL and PostGIS) versions, and as PostGIS is a
plugin to the backend, it's a plugin to the driver. It's not an
"ordinary Library", that's what JTS & co are, it's part of the driver.

> I guess that means no autoregistration and an unmodified getValue().
> Unmodified of what the JDBC driver offers without any addons.

We can discuss whether the autoregistration is sensible. It was meant
to make life easier for the users (simply dump the postgis.jar near the
pgjdbc.jar, and it works). But it seems to cause problems for others.

But if you want to get the data without any modification, you should
use the accessor functions, asHexEWKB() or asEWKB() in your case,
depending on whether you want text or binary representation. When using
those functions, you're independent of driver and backend versions, and
when using asWKT(), asWKB() and getSrid(), you're even portable across
OpenGIS compliant databases (although you lose some PostGIS extensions).

> It seems that the server can handle binary mode (LWGEOM_recv() and
> LWGEOM_send()), but I didn't find code in the JDBC driver that makes use of
> this. ?

Currently, the JDBC driver only supports text encoding, binary encoding
is in the works. The list pgsql-jdbc at postgresql.org is the right place
to discuss that specific issue (it was already discussed sometimes,
please scan the archives.)


Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org



More information about the postgis-users mailing list