RE: Re: AW: Re: OID wraparound: summary and proposal

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Alex Pilosov" <alex(at)pilosoft(dot)com>, "mlw" <markw(at)mohawksoft(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Re: AW: Re: OID wraparound: summary and proposal
Date: 2001-08-06 17:46:58
Message-ID: EKEJJICOHDIEMGPNIFIJKEDIFBAA.Inoue@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2001-08-06 17:47:10 RE: Possible solution for LIKE optimization
Previous Message Peter Eisentraut 2001-08-06 16:27:16 Re: user guide