Ola,
How are you planning on determining if the underlying data has been
changed by some other process? There is a system column called xmin
which can be used, however you will have to add it to the select.
Dave
-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Ola Sundell
Sent: June 26, 2001 6:23 PM
To: 'PostgreSQL jdbc list'
Subject: Re: [JDBC] Todo/missing?
On Tue, 26 Jun 2001, Thomas O'Dowd wrote:
> On Mon, Jun 25, 2001 at 10:56:18PM -0400, Dave Cramer wrote:
> > I have to agree, we need to compile a todo list.
> >
> > Mine would include:
> >
> > 1) Comprehensive test suite. This may be available already.
> > 2) Updateable resultSet
> > 3) Improved DatabaseMetaData
>
> That looks pretty good from where I stand. I would perhaps separate
> out also, the fact that the ResultSet.insertXXX() methods also need to
be
> implemented as well as the updateXXX methods. I guess this comes under
> the updateable resultSet but it's not clear.
I've been looking at the updateable ResultSet. The best way of
implementing it, imo, is adding (as I already mentioned) a property to
Field, which tells us where the Field is coming from. Without this,
we'll
have to parse the SELECT, to see where the Field originated, and imo
this
is way too complex to be done in the updateXXX methods. Unless anyone
has
a better idea, I'll implement this.
I'm working on the updateable ResultSet as I'm writing this. Everything
is
looking fine, although this might be a major overhaul. I'm re-reading
the
jdbc-2.1 spec, and I am consuming immense amounts of Coca-Cola. We'll
see
what it leads to.
Ola
--
Ola Sundell
ola@miranda.org - olas@wiw.org - ola.sundell@upright.se
http://miranda.org/~ola
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster