> Some other databases have the notion of a ROWID which uniquely
identifies a row
> within a table. OID can be used for that, but it means if you use it,
you must
> limit the size of your whole database system.
Imho that is getting it all wrong. OID is *not* a suitable substitute
for other
db's
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
On Mon, 6 Aug 2001, mlw wrote:
> I think you are focusing too much on "ROWID" and not enough on OID. The issue
> at hand is OID. It is a PostgreSQL cluster wide limitation. As data storage
> decreases in price, the likelihood of people running into this limitation
> increases. I have run into OID
> 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
I think you are focusing too much on "ROWID" and not enough on OID. The issue
at hand is OID. It is a PostgreSQL cluster wide limitation. As data storage
decreases in price, the likelihood of people running into this limitation
increases. I have run into OID problems in my curent project. Geez, 40
