Re: RE: Row Versioning, for jdbc updateable result sets

Stuart,

I had no idea that xmin even existed, but having a quick look I think this
is what I am looking for. Can I assume that if xmin has changed, then
another process has changed the underlying data ?

Dave
----- Original Message -----
From: "Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk>
To: "'Dave Cramer'" <dave@fastcrypt.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Friday, June 15, 2001 5:41 AM
Subject: [HACKERS] RE: Row Versioning, for jdbc updateable result sets


> Don't know about JDBC, but couldn't you just use UPDATE <xxx> SET
> <yyy>=<zzz> WHERE xmin=<stored/old xmin> AND primarykey=<stored/old pk>
and
> get the number of altered records? (if its zero then you know somethings
> wrong and can investigate further)
> - Stuart
>
> > -----Original Message-----
> > From: Dave Cramer [SMTP:dave@fastcrypt.com]
> > Sent: Thursday, June 14, 2001 4:34 AM
> > To: pgsql-hackers@postgresql.org
> > Subject: Row Versioning, for jdbc updateable result sets
> >
> > In order to be able to implement updateable result sets there needs to
be
> > a mechanism for determining if the underlying data has changed since the
> > resultset was fetched. Short of retrieving the current data and
comparing
> > the entire row, can anyone think of a way possibly using the row version
> > to determine if the data has been concurrently changed?
> >
> > Dave
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>