Re: datatype conversion thoughts

Kris,

How would PGDataType relate to PGObject?  I have always thought that
PGObject should be extended and used for all datatypes (not just
extensions).

--Barry

-----Original Message-----
From: Kris Jurka [mailto:books@ejurka.com]
Sent: Saturday, October 09, 2004 12:20 AM
To: pgsql-jdbc@postgresql.org
Subject: [JDBC] datatype conversion thoughts


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



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html