RE: OID wraparound (was Re: pg_depend) - Mailing list pgsql-hackers

From Henshall, Stuart - WCP
Subject RE: OID wraparound (was Re: pg_depend)
Date
Msg-id E2870D8CE1CCD311BAF50008C71EDE8E01F74638@MAIL_EXCHANGE
Whole thread Raw
In response to OID wraparound (was Re: pg_depend)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Would it be possible to offer an option for the OID column to get its value
from an int4 primary key (settable on a per table basis maybe)?
- Stuart

> -----Original Message-----
> From:    Hiroshi Inoue [SMTP:Inoue@tpf.co.jp]
> Sent:    Saturday, July 21, 2001 7:31 AM
> To:    Zeugswetter Andreas SB
> Cc:    PostgreSQL-development
> Subject:    RE: 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


pgsql-hackers by date:

Previous
From: Alessio Bragadini
Date:
Subject: Re: Neutral Soil (OT)
Next
From: Jan Wieck
Date:
Subject: Re: Large queries - again...