From: | Thor Michael Støre <thormichael(at)gmail(dot)com> |
---|---|
To: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
Cc: | Lukas Eder <lukas(dot)eder(at)gmail(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: UDT arrays |
Date: | 2011-02-13 18:03:29 |
Message-ID: | 1297620209.4457.3.camel@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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).
From | Date | Subject | |
---|---|---|---|
Next Message | RW Shore | 2011-02-14 10:28:07 | Array type error |
Previous Message | Lukas Eder | 2011-02-12 11:16:10 | Re: Fwd: [JDBC] Weird issues when reading UDT from stored function |