Abandoning PGobject

Hi,

There have been multiple discussions about new custom type
implementations on this list, and the necessary extensions that are
needed to allow binary transfer.

I just implemented the raw skeleton of my current idea how such thing
may work. It is based on what I remember from earlier.

The basic idea is that primitive types, Strings and byte[] are handled
by the driver directly, and all other built-in datatypes (e. G.
BigDecimal or Timestamp) as well as extension datatypes are handled by
this new model.

As it may make sense to call getInt on a BigDecimal, for reading all
methods are present, they are meant to be called 1:1 by the underlying
ResultSet. For writing, this is different, and everything can be handled
by a single setObject() method. I'm not really shure about which of the
given variants is the best one, so I included some of them.

It allows having different handlers for reading and writing, as well as
it allows a single handler to handle several sql and java types. It can
be made backwards compatible by including a TypeTextReader/
TypeTextWriter implementation that handles all PGobject subclasses.

This code is just a rough skeleton for my idea. I would like to get your
feedback what you think about it before I put too much effort into this.

Open issues are:

- What do you think about SUNs jdbc type map approach? I personally
think that, unfortunately, this is not flexible enough.

- How do we handle endianness? PostGIS canonical binary representation
includes endian information, but what about the other types?

- Handling of NULL values. I currently assume that the TypeDrivers are
not used for NULL values, because they can be handled in a type
independend manner by the driver itsself.

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(at)logi-track(dot)com | www.logi-track.com