datatype conversion thoughts

From: Kris Jurka <books(at)ejurka(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: datatype conversion thoughts
Date: 2004-10-09 07:19:37
Message-ID: Pine.BSO.4.56.0410090121590.25387@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc


I've been looking at a number of driver todo items that are all centered
around converting between datatypes. Specifically adding COPY support,
array handling, composite types (SQLInput/Ouptut), and binary data
transfer. All of these center around converting pg datatypes to Java
types and back.

The current driver currently operates on everything (except bytea) as a
String which is indeed easy to transform to and from with simple
operations like Integer.parseInt, but this only works if you're really
given an integer to begin with. The jdbc spec allows you to call getInt
on a variety of types, like floats, so it needs a fallback to handle that.
Also the driver allows you to call getInt on the deprecated pg money type.
This means that every time you call getInt() it has to perform operations
on the String it's given to determine if it's actually a money
value "-$12.11" and strip away the dollars sign. This can't be good for
performance.

Basically what I'd like to see is a datatype parsed only as the type it
actually is. We know what type the underlying data is, but at the moment
it's not used. For the money example above it would be parsed as money
and then converted to an int. This means you only pay the cost of parsing
the money type when you actually have money. This also cleans up the
other fallback parsing where say if we had a float column and called
getInt on it we wouldn't bother trying Integer.parseInt on it first and
then falling back to a float parsing method.

One way of doing this would be provide a PGDataType abstract class that
provided every getXXX method (getInt, getFloat, getBoolean, ...) which had
a default implementation of saying "Invalid conversion...". Then for each
datatype an implementation would be provided that could parse the
underlying data and perform whatever conversions that are applicable on
it. This would work the same way on the reverse side (converting from
java -> pg) as the implementation would provide a method for
converting to the format pg is expecting.

There are some isses about when and how this conversion happens regarding
excessive object creation or protecting a fixed set of these objects from
multithreaded access, but I just wanted to throw this basic concept out
there for any feedback.

Kris Jurka

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2004-10-09 10:23:22 Re: tightening up on use of oid 0
Previous Message Kris Jurka 2004-10-09 06:21:55 Re: Using gettext