
> As I mentioned already I'm implementing updatable cursors
> in ODBC and have half done it. If OIDs would be optional
> my trial loses its validity but I would never try another
> implementation.

But how can you do that ? The oid index is only created by 
the dba for specific tables, thus your update would do an update
with a where restriction, that is not indexed. 
This would be darn slow, no ?

How about instead selecting the primary key and one of the tid's 
(I never remember which, was it ctid ?) instead, so you can validate
when a row changed between the select and the update ?  

Andreas

Fri, 20 Jul 2001 16:45:19 +0200
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: OID wraparound (was Re: pg_depend)
> -----Original Message-----
> Zeugswetter Andreas SB
> 
> > As I mentioned already I'm implementing updatable cursors
> > in ODBC and have half done it. If OIDs would be optional
> > my trial loses its validity but I would never try another
> > implementation.
> 
> But how can you do that ? The oid index is only created by 
> the dba for specific tables, thus your update would do an update
> with a where restriction, that is not indexed. 
> This would be darn slow, no ?
> 

Please look at my another(previous ?) posting to pgsql-hackers.
I would use both TIDs and OIDs, TIDs for fast access, OIDs
for identification.

> How about instead selecting the primary key and one of the tid's 
> (I never remember which, was it ctid ?) instead, so you can validate
> when a row changed between the select and the update ?  
> 

Xmin is also available for row-versioning. But now I'm wondering
if TID/xmin are guranteed to keep such characteriscs.
Even Object IDentifier is about to lose the existence. 
Probably all-purpose application mustn't use system columns
at all though I've never heard of it in other dbms-s.

regards,
Hiroshi Inoue

Sat, 21 Jul 2001 15:31:13 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: OID wraparound (was Re: pg_depend)