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

Somehow I guess I created a misunderstanding. I don't really care about
ROWID. I care that OID is a 32 bit number. The notion that each table could
have its own "OID" similar to a ROWID could be an intermediate solution. I
have flip-flopped a couple times about whether or not the OID being able to
be eliminated from some tables is a good idea. Some code depends on the
OID.

I have hit OID problems personally. To be honest I think it can be a huge
problem. As I have said, 40G disks are under $100. Just a few years ago a
40G storage system would have cost $20K-$30K. BIG databases are being
created today, which wouldn't have been funded just a few years ago.  At my
company we have an aggregated database of 3 distinctly large databases, and
hit a bug in large OID numbers in 7.0.3.

The way I see it there are 4 options for the OID:
(1) Keep OID handling as it is. I think everyone agrees that this is not an
option.
(2) Allow the ability to have tables without OIDs. This is a source of
debate.
(3) Allow tables to have their own notion of an OID. This is harder to do,
and also a source of debate.
(4) Make OIDs 64 or 128 bit. (there are platform issues.)



> > 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl