Re: UDT arrays

Aaaah, thanks for asking that, Thormick. Good to know. I didn't realise
Radek was talking about any other JDBC implementation. I'll double check if
that Softperience driver will fix my problem. But then again, Radek, you
should have said so. I doubt that the pgsql-jdbc(at)postgresql(dot)org user group
should be about *YOUR *JDBC driver. I suggest you roll your own free user
group at google groups or elsewhere... Then again, may I ask you, why do you
roll your own driver? Why don't you contribute to the official one?

While I'm writing you, please have a look at your documentations link. It
seems to be broken:
http://softperience.eu/pages/cmn/ddd

I get a 404...

Cheers
Lukas

2011/2/14 rsmogura <rsmogura(at)softperience(dot)eu>

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