Re: datatype conversion thoughts
От | Oliver Jowett |
---|---|
Тема | Re: datatype conversion thoughts |
Дата | |
Msg-id | 416AFB6F.5060600@opencloud.com обсуждение исходный текст |
Ответ на | datatype conversion thoughts (Kris Jurka <books@ejurka.com>) |
Ответы |
Re: datatype conversion thoughts
(Markus Schaber <schabios@logi-track.com>)
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: