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, 40G 7200
RPM drives are $120, amazing.
Tom has proposed being able to remove the OID from tables, to preserve this
resource. I originally thought this was a good idea, but there are tools and
utilities others may want to use in the future that require OIDs, thus they
would have to be re-written or abandoned altogether.
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.
Zeugswetter Andreas SB SD wrote:
>
> > 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 ROWID.
>
> If you take a few extra precautions then you can use XTID in PostgreSQL
> instead of other's ROWID.
>
> We often hear, that it is safer to use ROWID in Oracle and Informix than
> in
> PostgreSQL. It is only true that the risc of getting at the wrong record
> is
> lower. Are you going to take chances when manipulating rows ? NO !
> Thus any sensible program working on ROWID's will have builtin
> precautions,
> like locking the table, or using additional where quals.
>
> I am still of the opinion, that we should invent an alias ROWID at the
> SQL level
> for the current XTID. I do not think that it matters what datatype this
> ROWID is,
> an arbitrary string like xtid is sufficient, it does not need to be an
> integer.
>
> Andreas
--
5-4-3-2-1 Thunderbirds are GO!
------------------------
http://www.mohawksoft.com