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.
having such an global_oid fits nicely with having table-uniqe oids.
just do
select 'mysite.'||text(tableoid)||'.'||text(oid) as global_oid from
mytable;
to get it
> 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.
Now that we have tableoid the need of globally unique oid is much
diminished.
> In reality, a 32 bit OID, even isolated per table, may be too small. Databases
> are getting HUGE. 40G disk drives are less than $100 bucks, in a few months 80G
> drives will be less than $200, one can put together 200G RAID systems for about
> $1000, a terabyte for about $5000. A database that would have needed an
> enterprise level system, just 7 years ago, can be run on a $500 desktop today.
And my PalmPilot has more memory adn storage and processor power than
PDP-11
where UNIX was developed ;)
So the real solution will be going to 64-bit OID's and XIDS, just that
some
platforms (I'd like to know which) dont have a good "long long"
implementation yet;
------------------
Hannu
