Re: datatype conversion thoughts

Kris Jurka wrote:
> 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.

> 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.

The basic concept is good. I was going in roughly the same direction
with ParameterList and friends.

To avoid threading/object creation issues you might want to look at a
strategy/flyweight implementation where the per-type codec objects are
stateless and are passed all the context they need, i.e:

interface ParameterCodec {
String getTextFormat(Object parameter);
byte[] getBinaryFormat(Object parameter);
void streamAsBinary(Object parameter, PGstream toStream);
// etc.
}

This would also mean you can construct (for example) codec instances for
Array types fairly painlessly; you have one instance per element type,
configured to delegate to the element's codec for converting the elements.

Also, separating the codec from storing the actual parameter data seems
like a win when you need to handle Array/COPY/SQLOutput etc, since they
all have different requirements.

For the ResultSet side and binary data, I was looking at reading the
entire DataRow message into a single array and passing array offsets to
the codecs. That should help reduce the amount of garbage generation:
we'd have one bytearray per row, not one per row per column.

For results where we do not yet have a binary-format parser, I realized
we can convert them to text on demand fairly easily: issue a "SELECT ?"
passing the uninterpretable binary data as the parameter value (with
correct type OID), and ask for results in text format. This should
hopefully mean we can do binary format results by default without having
to do an extra roundtrip to Describe the statement before every
execution (to work out which result columns to make binary); you only
pay the roundtrip cost when the user asks for a non-binary value, which
should hopefully be rare (e.g. external PGobject implementations that
haven't been updated for the changes).

I've done some more detailed design, mostly in my head at the moment; if
you want I can send you more details.

-O