Re: ctid & updates

From: Jan Wieck <janwieck(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joshua b(dot) Jore" <josh(at)greentechnologist(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: ctid & updates
Date: 2002-06-04 14:16:10
Message-ID: 200206041416.g54EGAH04751@saturn.janwieck.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> "Joshua b. Jore" <josh(at)greentechnologist(dot)org> writes:
> > I noticed that ctid changes on update (as expected since it's really a new
> > row). Is there anyway to get the new ctid from the update so later
> > updates to the row can continue to use ctid to zero in on the row
> > location?
>
> There's a function called something like currtid that takes the
> CTID of the possibly-obsoleted row and returns the CTID of its latest
> updated version. I believe this is exported because the ODBC driver
> uses it, so it's unlikely to go away, even though AFAIR it's not
> documented anywhere. A risk of using it is that CTID of an updated
> row cannot be trusted for very long --- once VACUUM has come by,
> you might find that CTID reassigned to some other row entirely.

But it should be safe within the transaction that did the
update, right? And since cursors (in PG) cannot span
multiple transactions, this would be the last piece I'm
looking for to use in UPDATE ... WHERE CURRENT OF.

Thanks.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2002-06-04 15:28:48 Re: ALTER TABLE
Previous Message Joshua b. Jore 2002-06-04 14:14:38 Re: second post: pg_dump and revision control