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