> -----Original Message-----
> From: Alex Pilosov
>
> On Mon, 6 Aug 2001, mlw wrote:
>
> > Zeugswetter Andreas SB SD wrote:
> > >
> > > > It seems to me, I guess and others too, that the OID
> mechanism should
> > > be on a
> > > > per table basis. That way OIDs are much more likely to be
> unique, and
> > > TRUNCATE
> > > > on a table should reset it's OID counter to zero.
> > >
> > > Seems to me, that this would be no different than a
> performance improved
> > > version
> > > of SERIAL.
> > > If you really need OID, you imho want the systemid tableid tupleid
> > > combo.
> > > A lot of people seem to use OID, when they really could use XTID. That
> > > is
> > > what I wanted to say.
> > >
> >
> > I don't care about having an OID or ROWID, I care that there is
> a 2^32 limit to
> > the current OID strategy and that a quick fix of allowing
> tables to exist
> > without OIDs may break some existing software. I was suggesting
> the OIDs be
> > managed on a "per table" basis as a better solution.
> Again, what existing software demands per-table OID field? Isn't it what
> primary keys are for?
>
I was just about to implement updatable cursors in psqlODBC using
TID and OID. I've half done it but the rest is pending now. I've had the
the plan since I introduced Tid scan in 7.0.
regards,
Hiroshi Inoue
