The analog of ROWID in PostgreSQL is TID rather than OID
because TID is a physical address of a tuple within a table.
However there's a significant difference. Unfortunately TID
is transient. It is changed by UPDATE and VACUUM.
Though TIDs are unavailable for critical use, OIDs could
compensate the drawback. TIDs and OIDs must help each
other if PostgreSQL needs the concept like ROWID.
regards,
Hiroshi Inoue
> -----Original Message-----
> From: mlw
>
> Hannu Krosing wrote:
> >
> > mlw wrote:
> > >
> > > I posted this question earlier, but it looks like it never made it on.
> > >
> > > If you can control the OIDs on a per table basis, and some
> tables need not even
> > > have any, why not let each table have its own OID range?
> Essentially, each
> > > record will be numbered relative to 0 on its table?
> > >
> > > That would really cut down the OID wrap around problem, and
> allow records to
> > > have a notion of serialization.
> >
> > What would the meaning of such an "OID" be ?
> >
> > Apart from duplicating the primary key that is ?
>
> 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. The other
> alternative is to make
> a column called "rowid" and a sequence for it and a default of
> nextval('table_rowid'). That means more work for those porting.
>
