Re: UDT arrays

I think it will be so, I want to add good support for this driver. You
should not afraid about this, many "not offical" drivers are better then
official releases, e.g. BEA had own driver for Oracle DB, as well I
worked with one driver,I don't remember vendor, to IBM DB2 better then
official.

I currently write small user registration app, I have virtual mailboxes
to hide true user e-mails in bugzilla. I looking for good "forum".

Kind regards,
Radek

On Sun, 13 Feb 2011 19:03:29 +0100, Thor Michael Støre wrote:
> Excuse me for butting in, but am I right in understanding that you're
> only talking about the Softperience JDBC driver, not the official
> one?
>
> http://softperience.eu/pages/cmn/ngpgjdbc.xhtml
>
> Like Lukas I'm also writing a database tool (though mine works on
> rather
> different principles), and I'm also extremely interested in support
> for
> UDT's and arrays of UDT's.
>
> - thormick
>
> On Thu, 2011-02-10 at 11:26 +0100, Radosław Smogura wrote:
>> I plan to sleep PGObjects, and wake for backward compatibility
>> (maybe as
>> deprectaed or some parts of methodes there - there are static
>> methods, which
>> causes problems with JDBC4 Exception model and some per connection
>> specific
>> functionaly). Arrays parsing is different in text and in binary
>> mode, and
>> binary mode requires more carefull casting. Actually current flow
>> should allow
>> to read any nested type, which is supported by ResultSet, form
>> parent object
>> (I putted only exception for getting result set with
>> multidimensional arrays).
>>
>> I plan to give support for specific PG objects like box, but make
>> them more
>> portable, without internal connection with JDBC dirver logic (you
>> should be
>> able to serialize and deserialzie those objects on clients without
>> postgresql.jar). I plan as well to give "plugable" support for
>> custom PG
>> objects, which can't be processed as UDT (above box is example). I
>> think about
>> mapping some PG objects to standard Java classes e.g. PG's box ->
>> java.awt.Box
>> (but this is far future). Above must be done in descriptive way, to
>> be usable
>> with DataSource and app servers, eg.
>>
>> @Resource
>> private DataSource myPgDataSourceWithMyCustomObjects
>>
>> Both of those should be designed in fast way, low memory consuption
>> and in way
>> preventing writing thousend lines of code if binary format for given
>> object
>> will be different per DB level or per new protocol (see e.g.
>> problems with
>> bytea encoding in 9.x releases).